Workflow behavior

Stakeholders describe how the business operates rather than naming Pega capabilities. The Solution Designer identifies the expected path, system-performed work, and business variation before deciding how each should be represented in the Workflow.

As you review Elena's account, look for the expected progression of work, the actions performed by participants, systems, or AI Agents, and the business circumstances that could change what happens next. The account describes both what normally happens and situations that require the business to respond differently.

Several parts of Elena's account describe circumstances that can change how the Case progresses:

The following figure shows how business circumstances can require different Workflow responses:

These variations do not all require the same design element. Some select a path, some determine whether work runs, some make additional work available, and some lead toward another recognized outcome.

The initial interpretation provides the starting point for the Workflow design. Guardian consent, for example, requires the Solution Designer to establish when consent applies, whether the Case can continue while it is outstanding, and what happens when consent is or is not provided. A later change in weather may require the booking to pause, reschedule, or follow another path. The design of dependencies and Wait Steps is developed with Case relationships.

Evaluate the analysis

Use the following questions to test whether the business behavior is understood:

• What normally happens?
• What should the system perform?
• What information or circumstances change the work?
• What does each variation require the Case to do?
• Does the variation continue toward the intended outcome or another recognized outcome?
• Which actions are best performed by a participant, the system, or an AI Agent?
• What Workflow controls are required before and after any Agent-driven action?

With the business behavior understood, the next step is to make the expected Process flow clear.

With the expected behavior understood, the next Workflow decision is determining how work normally progresses toward the Process outcome. Confirm that the Steps occur in a logical order, that each Step has the information it requires, and that the Process produces a meaningful outcome before progression continues.

Where a Stage contains multiple Processes, evaluate how those Processes relate to one another. Some Processes depend on the outcome of another Process before they can begin. Others can progress independently while still contributing to the same Stage milestone. Understanding these relationships helps ensure that work progresses efficiently while maintaining a clear path toward the intended outcome.

Within the Booking Requested Stage, the goal of the Evaluate Booking Request Process is to determine whether the booking can proceed. The expected path through the Process should reflect how the business gathers information, evaluates the request, and reaches a decision about the booking.

Evaluate the expected path

Use the following questions to evaluate the Process flow:

• Does the sequence reflect how the business expects the work to progress?
• Does each Step contribute to the outcome the Process is intended to achieve?
• Is the information required by each Step available when needed?
• Are dependencies between Steps clear?
• Are user-driven, system-driven, and Agent-driven actions represented appropriately?
• Can stakeholders explain why the work occurs in that order?

The expected path should show how the Process achieves its intended outcome without attempting to represent every variation. Later sections introduce the Workflow behavior that changes, extends, or redirects that progression when business circumstances require a different response.

Coordinate independent work with parallel Processes

After defining the expected progression within a Process, evaluate how the Processes within a Stage contribute to achieving the Stage milestone.

A Stage can contain more than one Process. These Processes normally run in sequence, so the next Process begins after the preceding Process completes. When two or more Processes contribute independently to the same Stage milestone, they can run in parallel.

Parallel Processes allow separate areas of work to progress at the same time without introducing separate Case Types. The Stage continues to represent one meaningful point in the Case Lifecycle, and each Process remains part of the same Case outcome and management context.

Where an Agent-driven Process is being introduced progressively, the design may also need a participant-led path so that work can continue while the organization develops confidence in the Agent-driven result. Model this as an intentional Workflow path rather than treating it as a new Process relationship type.

Parallel Processes coordinate independent progression within one Case and Stage. Parallel Child Cases coordinate independently managed outcomes that contribute to a Parent Case.

As the design evolves, some areas of work may indicate the need for a related Case Type rather than another Process. Signals can include the need for a distinct outcome, lifecycle, ownership, timing, status, reporting, or resolution. Topic 4 explores Case relationships and hierarchy in more detail.

Evaluate the Process relationship

• What outcome is each Process expected to achieve?
• Does one Process depend on the outcome of another before it can begin or complete?
• Can each Process progress independently?
• Do the Processes contribute to the same Stage milestone?
• Can each Process begin and progress without the result of the other?
• Must all required Processes complete before the Stage advances?
• Is each area of work managed specifically for this Case, or could it support a broader operational need?
• Does either area of work need its own outcome, Lifecycle, ownership, timing, status, or reporting?
• Does Agent-driven work require a participant-led path  when business controls require participant involvement?
• Would parallel progression within the Case keep ownership and dependencies clear?

The expected path represents how most applicable Cases progress toward a Stage milestone. In practice, business circumstances can require a different response, additional work, or an alternative path.

The Solution Designer's responsibility is to identify how the Case should respond when business circumstances differ from the expected path. Some variations require the Case to choose a different path. Others determine whether work applies to the Case at all. Some make additional actions or Processes available when needed.

Workflow design uses Decisions, Business Rules, conditions, and optional behavior to determine how the Case responds when circumstances differ from the expected path. The Solution Designer's responsibility is to identify what business question must be answered, what information is required, and what should happen as a result.

When variation changes what happens next

Some business circumstances require the Case to evaluate information and determine how work should continue. Decisions and Business Rules help the Workflow select the appropriate path.

Use Decisions to select a path

A Decision shape creates a point where the Process flow can follow different paths. The Decision evaluates business logic and directs the Case to the path associated with the result. In Blueprint, this behavior is represented through a Decision Step connected to a Business Rule.

Applied to Elena’s account, availability, tide, weather, tour type, and participant experience may all affect whether the booking can proceed. The design must make the business question, the logic used to answer it, the possible results, and the destination for each result clear.

The business question drives both the decision logic and the resulting Workflow path. Once the question is clear, select the Rule type that best represents the logic needed to answer it.

Match the Rule to the business question

Different Rule types are suited to different kinds of business questions. A When Rule returns a true-or-false result. A Decision Table evaluates combinations of conditions and returns one or more defined outcomes. Select the Rule that best matches the business question being asked.

For Tour Booking, a When Rule can evaluate whether the tour can proceed. The Decision uses the returned result to direct the Case to the appropriate path.

The following figure shows how a Decision uses a Business Rule to direct the Case to the appropriate Workflow path:

Evaluate the Rule and its results

Use the following questions to test whether the Rule and its results are clearly defined:

• What business question must the Rule answer?
• What information is required to answer it?
• Are the conditions and possible results clear and agreed?
• Who owns the business logic?
• What should each result cause the Case to do?
• Could the same Rule be reused at another Decision point?

Determine whether work applies

Use conditional execution when a business circumstance determines whether a Stage, Process, or Step applies to the current Case. Rather than selecting a different path through the work, conditional execution determines whether the work applies, allowing the Case to complete the work when required or skip it when it does not.

Applied to Elena’s account, guardian consent is required when a participant is under 18. Specialist equipment preparation may apply only to selected tour types. The condition should be connected to the work it controls and to what the Case does when the condition is not met.

Evaluate the condition and the controlled work

To evaluate the condition and the controlled work, consider the following questions:

• What business circumstance determines whether the work applies?
• Does the condition control one Process or an entire Stage?
• What should the Case do when the condition is true?
• What should the Case do when the condition is false?
• Must the conditional work complete before the Case can continue?

When a condition directs work to an AI Agent, establish what the Workflow should do when the Agent cannot complete the action, returns a result that does not meet the required acceptance criteria, or requires participant involvement. Where the business needs a participant-led path, represent that path explicitly.

Make optional work available

Not all work is required as part of the expected path. In some situations, participants need the ability to perform additional actions or initiate additional Processes when the business need arises.

Use optional behavior when work should be available but not required for every Case.

An Optional Action makes one user action available outside the expected Process flow. An Optional Process makes a related set of Steps available. The user starts the work when the business need arises rather than the work running for every Case.

Three ways to respond to variation

Select the behavior that matches the business need. 

The following figure shows three ways the Workflow can respond to business variation:

Optional behavior is different from conditional execution. Conditional work is required when its condition is met. Optional work remains available for a user to start when needed.

Evaluate whether the work is genuinely optional

To evaluate whether the work is genuinely optional, consider the following questions:

• Should a user decide when to start the work?
• Is the work one action or a related set of Steps?
• When should the option be available?
• Who should be able to start it?
• What should happen after it completes?
• Is the work optional, or required whenever a condition is true?

By this point, the Workflow defines how work progresses and how it responds to variation. The next design decision is determining who or what performs the work required to achieve the business outcome.

The Solution Designer selects how each action is performed according to the nature of the work. The Workflow coordinates the resulting user-driven, system-driven, and Agent-driven actions.

The following figure shows the three ways work can be performed within the Workflow:

Perform work automatically

Use an Automation Step when the system can perform a defined business action without participant judgment, interpretation, or analysis, and a more specific Blueprint Step type does not already represent that behavior.

Automation Steps represent system-driven work that contributes directly to Case progression. Examples include reserving equipment, updating Case data, synchronizing information with external systems, or performing another defined business action that follows agreed business logic.

Blueprint represents many forms of system-driven work through a small set of Step types. Some activities, such as creating related Cases, generating documents, sending notifications, waiting for an event or dependency, or performing AI-enabled work, have their own dedicated Step types. Other system actions are represented through an Automation Step.

The Solution Designer's responsibility is to preserve the business intent. Describe the business action being performed, the information required to perform it, the expected result, and any conditions, dependencies, or outcomes that the Workflow relies on afterwards. This information provides the Solution Builder with the context needed to determine the most appropriate implementation during Authoring.

Applied to Elena's account, the system might reserve equipment required for the selected tour, update booking information, or synchronize booking details with an external provider. The important design decision is what the system must accomplish and what the later Workflow can rely on as a result.

Place automation where its result is needed

To evaluate the Automation Step, consider the following questions:

• What business action should the system perform?
• What information must be available?
• What result, update, or integration outcome should the Step produce?
• What conditions, dependencies, or outcomes should be preserved for implementation?
• Where does the action belong in the Process flow?
• What should happen if the action does not complete as expected?
• Does the Step name describe the business action clearly?

Perform work through an AI Agent

An Agent-driven Step enables an AI Agent to perform a defined business action within a Process. Use Agent-driven work where the action requires interpretation, analysis, synthesis, extraction, classification, or drafting across the data, information, knowledge, and context available to the Case.

The AI Agent performs the assigned business action. The Workflow remains responsible for determining when the action occurs, providing the required context, evaluating the result, applying business controls, routing exceptions, and controlling how the Case progresses.

Applied to Elena’s account, an AI Agent could draft a tailored booking confirmation using the confirmed booking details, participant characteristics, weather information, and relevant tour guidance. The Workflow determines when the draft is created, which inputs are provided, where the result is captured, whether participant review is required, and when the communication can be sent.

Keep AI Agent actions and Workflow responsibilities distinct

An Agent-driven Step should represent a specific business action that benefits from AI Agent involvement. An experienced Solution Designer clearly defines the responsibility of the AI Agent and keeps Workflow responsibilities separate.

Workflow remains responsible for sequencing work, applying business and risk controls, managing exceptions, evaluating results, and determining how the Case progresses.

For the booking confirmation example, the AI Agent drafts the message while the surrounding Workflow provides the context, defines the required output, and determines how the Case proceeds.

The following figure shows how an Agent-driven Step works within the surrounding Workflow:

Define the result the Workflow can use

Describe the information the Workflow provides to the AI Agent and the result the Agent must return. Identify the Case fields in which the required output is captured so that subsequent Steps, Decisions, and participants can use it.

Where the Workflow must evaluate confidence, classification, risk, or another aspect of the result, define that value as part of the required output. Avoid relying on an unstructured narrative where the Workflow requires explicit values to determine progression.

Place appropriate oversight and continued progression

Determine the oversight required from the business impact, risk, confidence, and reversibility of the result. Participant review may be required before the Case commits an irreversible action, communicates a high-impact result, or progresses where the Agent’s output does not meet agreed acceptance criteria.

As evidence and confidence develop, suitable work may progress with participant involvement focused on exceptions. The Workflow should continue to enforce the agreed checks, routing, and business controls.

Evaluate the Agent-driven Workflow

To evaluate the Agent-driven Workflow, consider the following questions:

• Is the action genuinely cognitive, or can it be completed through deterministic Workflow, automation, or decision logic?
• What business result must the AI Agent produce?
• What data, information, knowledge, and Case context must be available before the Agent acts?
• In which Case fields will the required result be captured?
• What must the Workflow validate after the Agent-driven Step?
• What acceptance criteria determine whether the Case continues?
• When is participant review, confirmation, or authorization required?
• What path applies when the Agent cannot complete the action or its result does not meet the required criteria?
• Could the Process support straight-through progression while routing defined exceptions for participant involvement?
• Are high-impact or irreversible actions protected by an appropriate Workflow-controlled gate?

By this point, the Workflow design should describe:

• How work normally progresses
• How the Workflow responds to variation
• How work is performed
• How the Case progresses toward each Stage milestone

Before moving on, review the complete Workflow as a single business explanation. Stakeholders should be able to understand what normally happens, what can vary, who or what performs the work, and where each meaningful outcome leads.

Place additional behavior where it belongs

Add Workflow behavior where it first influences progression.

System-performed work should appear where its result is required. Decisions should appear where information changes what happens next. Conditions should determine whether work applies. Agent-driven work should appear where its result contributes to achieving a Process outcome.

Variation can remain within the current Process when the Case is still working toward the same outcome and only the actions required have changed. Movement to another Stage becomes relevant when the Case reaches another meaningful milestone in its lifecycle.

Every meaningful result should have a clear continuation path. When a Decision, condition, Automation Step, or Agent-driven Step produces a result, the Workflow should make it clear what happens next and how work continues toward the intended or alternate outcome.

Evaluate Workflow placement

To evaluate the Agent-driven Workflow, consider the following questions:

• Where does the expected progression first change?
• What causes the change?
• Does the Workflow behavior appear where it first influences progression?
• Does the Case remain within the current Process or move toward another lifecycle milestone?

Validate the Workflow design

The Workflow design elements developed in this topic must work together as one business explanation. The design should show what normally happens, what the system performs, what can vary, and where each meaningful path leads.

Review the connected Workflow behavior

Review the Workflow as one business explanation:

• Is the expected progression of work clear?
• What business circumstances change that progression?
• Does the Workflow respond appropriately to those circumstances?
• Are user-driven, system-driven, and Agent-driven actions used where they create the most value?
• Can stakeholders explain how the Case reaches its intended and alternate outcomes?
   

Workflow behavior determines how work moves and changes within the Case structure. Process flow represents the expected sequence and paths through a Process. Parallel Processes allow independent areas of work within the same Stage to progress at the same time toward the Stage milestone.

Automation Steps allow the system to perform deterministic work. Agent-driven Steps enable AI Agents to perform defined cognitive actions within Workflow-controlled boundaries.

Decision shapes, When Rules, Decision Tables, conditional execution, and optional behavior allow the Case to respond to business variation.

Experienced Solution Designers use Workflow to coordinate user-driven, system-driven, and Agent-driven work, preserving the checks, oversight, exceptions, and destinations needed for reliable progression.

Experienced Solution Designers keep the expected path clear, select each Workflow design element for the behavior it provides, and preserve enough business intent for stakeholder validation and Authoring.

With Workflow behavior established, Topic 3 develops how user-driven work is assigned, routed, authorized, and managed through operational commitments.

Check your knowledge with the following interaction.