Work Orchestration

Work orchestration decisions build on one another. First establish ownership of the work, then determine how information is collected, whether responsibility is shared, where authorization is required, how commitments are protected, and whether participants can successfully complete the work. Review these decisions together to confirm that the operating model remains clear as people, teams, workloads, and priorities change.

Stakeholders describe responsibility, authority, collaboration, and timing in business terms. The Solution Designer separates these needs before deciding how each one should be represented in the design.

Experienced Solution Designers look beyond the individual people mentioned in a stakeholder discussion and focus on the responsibilities being described. They identify where responsibility belongs to a specific participant, where it can be shared across a team, where formal authorization is required, and where operational commitments need visibility or intervention. The resulting design should continue to represent the business clearly even as people, teams, and organizational structures change

The following questions are used to determine work orchestration:

• Who is responsible for completing each user-driven Step?
• Does the work belong to one participant or can an eligible team member complete it?
• Where does the business require formal authorization or accountable judgment?
• What timing commitment applies, and who must act when that commitment is at risk?
• Can the intended participant reach the Assignment and access the information required to complete it?

Every user-driven Step requires a clear business owner. Before selecting a routing approach, determine who is responsible for completing the work and whether that responsibility belongs to a specific participant, a business role, or another user already identified by the Case.

The Solution Designer's responsibility is to preserve that ownership clearly in the design. Routing should reflect how the business intends the work to be completed rather than how the organization happens to be structured today.

Once the ownership model is understood, the Route To options in Pega Blueprint™ provide different ways to represent that responsibility. Select the option that best matches the intended business ownership and how the Assignment should reach the appropriate participant.

The Solution Designer makes the ownership model explicit. For example, in the Tour Booking application, an Assignment can be routed based on five distinct ownership patterns.

The following figure shows the five routing options used to represent distinct Assignment ownership patterns:

A Persona identifies the business role responsible for completing the Step. Selecting a Persona establishes the responsibility, although it does not determine how that responsibility is fulfilled. The Assignment might be directed to one identified participant fulfilling that role, or it might be shared by eligible members of a team.

The Solution Designer should make that ownership model explicit. Clarifying whether responsibility belongs to an individual or a team helps ensure that the routing approach supports the way the business intends the work to be completed and provides the information needed during Authoring.

Evaluate the routing design

To evaluate the routing design, consider the following questions:

• Does the responsibility belong to one user fulfilling the Persona or is it shared by a team?
• If one user must receive the Assignment, how should that user be identified?
• Will the routing remain appropriate as people and responsibilities change?

As AI Agents become part of everyday business Workflows, the Solution Designer identifies where human involvement is required and determines how people supervise Agent-driven work.  This generally follows two patterns: people supervising Agent-driven work through human-in-the-loop, or people handling exceptions or complex Cases through human-on-the-loop.

When designing a Workflow, identify where AI can accelerate work and how people retain appropriate control:

• Human supervision: Some Agent-driven Steps require a user to review, confirm, or override the AI Agent’s result before the Case continues.
• Human involvement for exceptions or complex Cases: Routine system-driven and Agent-driven work can progress without individual review. A user becomes involved when an exception occurs, a result has low confidence, the Case requires additional judgment, or an action requires confirmation or authorization.

Supervision should reflect the business significance of the work and the responsibility that remains with people. The design must establish what requires human attention, who is responsible for acting, what information they need, how the work reaches them, and what their response allows the Case to do next.

Applied to Elena’s account, an AI Agent could prepare a booking confirmation using booking, participant, weather, and tour information. U+ Travel may require a Tour Operator to review every confirmation before the Case continues. Where routine confirmations can progress without individual review, the Workflow applies agreed acceptance criteria and determines whether human attention is required. Missing information, low-confidence results, defined exceptions, and complex Cases requiring additional judgment are directed to a Tour Operator.

The following figure shows two patterns for human supervision of Agent-driven work:

The Solution Designer also identifies when formal authorization is required and which participant has the appropriate authority.

The Workflow evaluates the Agent’s result and creates and routes an Assignment when human attention is required. The design should identify the conditions that require involvement, the participant or Persona responsible for acting, the information they need, and what their response enables. Where supervision focuses on exceptions, also define the results or conditions that allow routine work to continue without human review.

Evaluate the supervision design

To evaluate the supervision design, consider the following questions:

• What responsibility remains with people when the AI Agent performs the action? 
• Which results require human review, and which can support routine progression? 
• What conditions trigger human attention, and what type of involvement is required? 
• Which participant or business role has the responsibility or authority to act? 
• What information must the person receive, and how should the resulting Assignment be routed? 
• What should the person’s response enable the Case to do next?

With responsibility, supervision, and routing established, the next design decision is determining how information is collected from participants. Some user-driven Assignments require review, judgment, or decision-making. Others primarily exist to obtain information, documents, confirmations, or updates needed for the Case to continue.

Where the primary purpose of an Assignment is collecting information from a specific participant, Agentic Assignment Processing may provide a more efficient interaction model.

Applied to Elena's account, operators may need additional participant details, supporting documentation, or booking confirmations before preparation can continue. Where the primary purpose of the Assignment is obtaining information from a specific participant, Agentic Assignment Processing may provide a more efficient way to support that interaction.

Agentic Assignment Processing allows a Pega GenAI™ Agent to support an eligible user-driven Assignment through email. When the Assignment is created and routed to a specific operator or external user, the AI Agent sends a request for the required information or documents. The Assignment owner replies to the email, and the AI Agent processes the response, extracts and validates the information, and completes the Assignment so that the Case can continue.

Use Agentic Assignment Processing to reduce manual latency and repeated human follow-up. It is suited to routine information collection where a specific participant needs to provide details, answer a question, or submit a document. Instead of requiring the participant to access the application and complete the Assignment directly, the AI Agent manages the interaction through email while the participant remains the source of the required information. 

In Blueprint, select the target user-driven Step and enable Agentic Assignment Processing. Record the monitored business email account used for the interaction in the Step Notes and route the Assignment to a specific operator or external user.

Evaluate the agentic Assignment design

To review the connected design, consider the following questions:

• Is the Assignment primarily a routine information request that can be completed through an email interaction?
• Is the Assignment routed to a specific operator or external user?
• What information or documents must be provided before the Case can continue?
• Does the design remain within the supported Agentic Assignment Processing constraints?

When responsibility belongs to a team rather than a specific participant, the Assignment should be available to eligible team members instead of being routed immediately to one individual. Shared responsibility allows work to continue through available and qualified participants while preserving accountability for the business outcome.

In Pega Infinity™, a Work Group represents the responsible team, and its Work Queue holds the Assignments available to eligible team members.

A Work Group has a manager, a Work Queue, and eligible members who share responsibility for the work. A user can belong to more than one Work Group. Only eligible members complete work from the Work Queue.

Applied to Elena’s account, any eligible Tour Operator can complete the standard booking checks. In Blueprint, the Tour Operator Persona represents this business responsibility. The Step description preserves that the Assignment is shared and should be made available through the team’s Work Queue during Authoring

Define how the team shares the work

Shared responsibility requires more than identifying the team that owns the work. The Solution Designer must also determine how the work becomes available, who is eligible to complete it, how responsibility is monitored, and what influences work selection. These decisions help ensure that shared ownership remains clear and operationally effective as workload and staffing change.

Assignments remain in a Work Queue until an eligible user selects the work, a manager assigns it to a specific user, or Automated Work Assignment selects an appropriate Assignment. Selection can consider criteria such as Assignment Urgency, user availability, and skill set.

Some business decisions can be applied consistently through agreed rules. Others require accountability from an authorized participant who must review the situation and make a decision. The Solution Designer evaluates where formal authorization or accountable judgment adds business value before deciding how that decision should be represented in the Workflow.

Use an Approve/Reject Step when the business requires formal authorization, accountable judgment, or attestation from an authorized participant. A Decision applies defined logic automatically; an Approve/Reject Step creates an Assignment and waits for a participant to decide.

An automated Decision evaluates rules without pausing the Workflow. In contrast, an Approve/Reject Step pauses the Case to wait for accountable human judgment, requiring explicit design for both approval and rejection outcomes.

The following figure shows how an automated Decision differs from an Approve/Reject Step:

Establish the value of the Approval

To establish the value of the Approval, consider the following questions:

• What requires authorization, and what risk or obligation makes it necessary?
• What authority or judgment does the reviewer exercise?
• What information must the reviewer see?
• Which participant is authorized to decide?
• Should the Approval route to a specific user, a Work Queue, or a destination selected through business logic?
• What should happen after Approval and after rejection?

Work orchestration is not limited to assigning responsibility. The Solution Designer must also determine which commitments the business needs to protect and how the organization should respond when those commitments are at risk. Some work simply needs to be completed. Other work carries timing expectations that affect customers, operations, compliance obligations, or business outcomes.

A Service-Level Agreement (SLA) expresses a timing commitment and the action taken if that commitment is approached or missed. An SLA can apply at the Case, Stage, Process, or Step level.

Applied to Elena’s account, a booking response may be required before a tour slot is lost. Equipment preparation must complete before the operational cut-off. A weather change may require immediate attention, while guardian consent must arrive before departure.

Define the timing and response

SLA timing starts when the Case, Stage, Process, or Step begins. The Goal is the desired completion interval. The Deadline defines when the work becomes late. A Passed Deadline Interval can repeat after the Deadline when further action is required.

Case Urgency represents the relative priority of the Case. Assignment Urgency represents priority in a user’s Worklist or a team’s Work Queue. Assignment Urgency can be combined with user availability and skill information when automatically selecting eligible work.

Notifications from SLAs can inform the current assignee, the assignee’s manager, or selected Case participants. Escalation may reassign the Assignment to another user or Work Queue or apply another action.

The following figure shows how Goal, Deadline, and Passed Deadline intervals structure an SLA:

Evaluate the operational commitment

To evaluate the operational commitment, consider the following questions:

• What commitment is being protected?
• At what level is it measured?
• What are the Goal and Deadline intervals?
• Is a Passed Deadline Interval required?
• What should change at each threshold?
• Who must know or act?
• Should ownership remain or transfer?
• Can stakeholders explain and defend the timing and response?

Work orchestration decisions are most effective when they are reviewed as a connected operating model rather than as individual configuration choices. Routing establishes ownership, Agentic Assignment Processing determines how eligible information is collected, Work Queues support shared responsibility, Approvals apply authorized judgment, and SLAs protect operational commitments. Together, these decisions determine how work reaches the right participant, how accountability is applied, and how the business responds when attention or intervention is required.

Review the Tour Booking design as one connected orchestration model. Confirm that ownership, team responsibility, authorization, commitments, and participation requirements work together to support the intended business outcome and remain understandable as people, teams, workloads, and priorities change.

Review the connected design

To review the connected design, consider the following questions:

• Does every user-driven Step have a clear business owner?
• Is responsibility assigned appropriately to an individual or shared team?
• Is information collected and validated using the most appropriate interaction model?
• Is formal authorization used only where accountable judgment is required?
• Does each SLA protect a genuine business commitment with an appropriate response?
• Can the participant receive the Assignment, access the required information, and act through the intended Channel?

Work orchestration determines how responsibility, authorization, operational commitments, and participation requirements are represented in the design. Routing establishes ownership, Work Queues support shared responsibility, Agentic Assignment Processing supports eligible information collection, Approvals apply authorized judgment, and SLAs protect business commitments. Together, these decisions define how work is assigned, completed, supervised, and escalated throughout the Case lifecycle.

Experienced Solution Designers preserve the business ownership represented by the routing, use Approval where it provides accountable value, and define timing responses that stakeholders can explain and defend.

With Case structure, Workflow behavior, and Work Orchestration established, Topic 4 examines when related work should remain within the Tour Booking Case and when it should become a focused Case Type with its own Lifecycle, participants, timing, and dependencies.

Check your knowledge with the following interaction.