3.1 Multi-Step Processes, Parallel Processing & Sub-processes

3.1 Multi-Step Processes, Parallel Processing & Sub-processes

CSA Exam Focus: Mastering advanced workflow execution patterns is a core requirement for the Certified Pega System Architect exam. Pega workflows often require concurrent execution across multiple departments, dynamic iterations over collections of items, and background processing. Candidates must understand how sequential and parallel processes behave within stages, how to configure Flow rules with Sub-process, Split Join, and Split For Each shapes, and how locking strategies (Default vs. Optimistic) impact concurrent assignment processing.

---

Sequential vs. Parallel Processes within Case Stages

In Pega Case Designer, stages represent primary milestones in the case lifecycle. Each stage contains one or more processes, which in turn contain steps (assignments, automations, approvals). Understanding how processes execute within a stage is fundamental to architecting efficient business workflows.

Sequential Processes

By default, processes within a stage execute sequentially. When a case enters a stage, the first process initiates. The case remains in that process until the final step completes or reaches an End shape in its underlying flow rule. Only then does the case engine advance to the next process configured in the stage.

Sequential execution is required when there is a strict business dependency between phases. For example, in an automobile loan application, the Credit Evaluation process must fully complete and return an approved credit tier before the Loan Pricing & Offer Calculation process can run. Running them simultaneously would result in missing input data.

Parallel Processes

Enterprise scenarios frequently require multiple teams or systems to perform work at the same time without waiting for each other. Pega supports parallel processes directly within a stage. When multiple processes in a stage are configured to start in parallel, Pega initiates each process concurrently as soon as the case enters that stage.

Consider an Employee Onboarding case entering the "Fulfillment" stage:

• IT Provisioning Process: Allocates a laptop, configures VPN access, and issues software licenses.
• Facilities Management Process: Assigns a desk location, programs a security badge, and reserves parking.
• HR Benefits Orientation Process: Schedules benefits consultations and enrolls the worker in retirement plans.

Each of these processes executes concurrently. Pega creates separate assignments for each process on the parent case. The stage cannot complete until all parallel processes have finished their respective workflows, establishing a natural synchronization barrier before advancing to the next stage.

In App Studio, architects configure parallel processes by selecting the process in Case Designer and setting the start behavior to Start process when stage starts, rather than waiting for prior processes to finish.

---

Flow Rules and Sub-Process Patterns in Dev Studio

While App Studio allows high-level configuration of stage processes, Dev Studio provides visual workflow modeling through Flow rules (Rule-Obj-Flow). Within flow diagrams, specialized shapes enable sophisticated branching, delegation, and concurrency.

The Sub-Process Shape (Call Subprocess)

The Sub-process shape invokes an independent flow rule from within the current flow. This pattern promotes rule reusability and modularity by encapsulating complex multi-step routines (e.g., Address Verification, Fraud Scrub, Document Archive) into standalone flow rules that multiple case types can reuse.

Pega provides two distinct operational modes for the Sub-process shape:

1. Synchronous Sub-process (Standard Call): Execution transfers to the invoked sub-process. The parent flow pauses at the Sub-process shape. When the sub-process reaches an End shape, execution returns to the parent flow, which immediately advances to the next shape.
2. Asynchronous Sub-process (Spin-off Flow): Enabled by selecting the Spinoff checkbox on the Sub-process shape properties panel. When a flow is spun off, Pega spawns an independent, concurrent thread of execution that runs in parallel with the main flow. The parent flow does not wait for the spun-off sub-process to complete—it proceeds immediately to the next shape. Spin-offs are ideal for fire-and-forget activities such as publishing audit logs, generating secondary notifications, or triggering asynchronous background verification tasks where downstream steps do not depend on the outcome.

---

The Split Join Shape: Concurrent Distinct Flows

The Split Join shape splits a single flow execution path into two or more distinct, specified sub-processes that run concurrently. Unlike a spin-off, a Split Join acts as a rendezvous point: the main flow pauses at the Split Join shape until a defined Join Condition is satisfied.

                    +----------------------------+
                    | Sub-process A: Underwriting|
                +-->| (Assigned to Credit Team)  +--+
                |   +----------------------------+  |
[Split Join] ---+                                   +---> [Join Condition Evaluator] ---> [Next Step]
                |   +----------------------------+  |
                +-->| Sub-process B: Compliance  +--+
                    | (Assigned to Legal Team)   |
                    +----------------------------+

Join Conditions

When configuring a Split Join shape in Dev Studio, the architect specifies the sub-processes to launch and selects one of three Join Conditions:

When using Any, architects must decide whether remaining open assignments should be cancelled automatically. If left unchecked, uncompleted assignments remain on operators' worklists even after the parent case has advanced.

---

The Split For Each Shape: Iterating Over Page Lists

While Split Join coordinates a fixed set of distinct flows known at design time, real-world applications frequently require processing a dynamic collection of items concurrently. The Split For Each shape addresses this need by iterating over a Page List or Page Group property.

For every page in the collection, Pega dynamically spawns an instance of a designated flow rule. All spawned instances run in parallel.

Runtime Mechanics of Split For Each

• Iteration Property: Must reference an aggregate property mode (typically a Page List, such as .LineItems or .DamagedProperties).
• Target Flow: The flow rule to execute for each page in the list. During execution of each sub-process instance, Pega sets the primary page to that specific page in the collection. This provides localized data context (e.g., .Price, .Quantity, .InspectionNotes) without needing parent path prefixes.
• Join Conditions: Like Split Join, Split For Each supports All, Any, and Some join conditions:
  • All: Waits until the sub-process has finished for every element in the Page List.
  • Any: Proceeds as soon as any single element finishes its sub-process.
  • Some: Evaluates a When rule after each item finishes (e.g., proceed once total approved line items exceed a dollar threshold, or halt if any single item is rejected).

Practical Example: Line-Item Expense Approvals

In a Corporate Expense Claim case, an employee submits an expense report containing 12 line items stored on the .ExpenseItems Page List. A Split For Each shape iterates over .ExpenseItems, spawning a ReviewExpenseItem flow for each item. Line items under $500 are auto-approved via an automated decision table step, while line items over $500 route to regional managers. The parent case pauses at the Split For Each shape until All line items are resolved, ensuring no reimbursement is issued prematurely.

---

Locking Implications during Parallel Processing

Parallel processing introduces critical architectural challenges regarding concurrency and data integrity. In Pega, case data is stored as a single serialized BLOB (Binary Large Object) in the database table (pc_work). When multiple users or system threads attempt to modify assignments on the same case simultaneously, locking conflicts can occur.

Pega provides two primary locking strategies configured on the Case Type rule (Rule-Obj-CaseType):

1. Default Locking (Pessimistic Locking)

• Mechanism: When an operator opens an assignment or a system process accesses a case for update, Pega acquires an exclusive lock on the case in the System-Locks table. The lock is held continuously until the operator submits the assignment, cancels the action, closes the tab, or the lock timeout expires (default 30 minutes).
• Limitation in Parallel Workflows: Only one operator can hold the lock at a time. If an Onboarding case spawns parallel assignments for IT Provisioning and Facilities Management, and both operators attempt to work on their respective assignments simultaneously, the second operator receives a lock collision error:

  "This case is currently locked by Operator Jane Doe. You cannot make updates at this time."

• This locks out users, causes workflow bottlenecks, and frustrates end users.

2. Optimistic Locking

• Mechanism: Allows multiple operators or background threads to open and work on assignments for the same case concurrently without locking the record upfront. Pega acquires the lock only momentarily during the commit operation when the user clicks Submit or when an automation persists data.
• Conflict Resolution: Pega tracks a case version counter (pzSaveCounter). When an operator submits an assignment, Pega verifies whether the case was modified by someone else while the operator was working:
  • If no concurrent changes occurred, the update commits cleanly.
  • If another user submitted changes in the interim, Pega detects the version mismatch and displays a modal prompt allowing the user to review the changes, merge their updates, or refresh the screen.
• Best Practice for Parallel Processes: Optimistic locking is strongly recommended for case types that utilize parallel processes, Split Join, or Split For Each shapes where assignments reside on the same parent case and multiple users are expected to collaborate concurrently.