Study guide
3.1 Multi-Step Processes, Parallel Processing & Sub-processes
Pegasystems Certified Pega System Architect CSA
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Architecture Foundations
1.1 Certified Pega System Architect Exam Format, Blueprint & Strategy 1.2 Pega Architecture & Enterprise Class Structure (ECS) 1.3 Studio Environments: App Studio, Dev Studio, Admin Studio & Prediction Studio
2 Chapter 2: Case Lifecycle Design & Core Workflows
2.1 Case Types, Stages, Processes, and Steps 2.2 Routing Strategies: Worklists, Work Queues, and Teams 2.3 Service Level Agreements (SLAs) & Urgency Calculations
3 Chapter 3: Advanced Case Management Patterns
3.1 Multi-Step Processes, Parallel Processing & Sub-processes 3.2 Child Cases, Data Propagation & Wait Steps 3.3 Optional Actions, Approvals & Case Resolution 3.4 Duplicate Case Detection, Automation Shapes & Automated Correspondence
4 Chapter 4: Data Modeling & Data Page Architecture
4.1 Data Objects, Property Modes & Page Types 4.2 Data Pages: Scope, Types & Refresh Policies 4.3 Data Transforms & Object Mapping
5 Chapter 5: Business Logic, Calculations & Decisioning
5.1 Declare Expressions & Declarative Network Chaining 5.2 Decision Tables & Decision Trees 5.3 Integration Connectors, Systems of Record & Error Handling
6 Chapter 6: User Interface & User Experience Design
6.1 Traditional UI vs Constellation Architecture 6.2 Views, Dynamic Layouts, Design Templates & Action Sets 6.3 Form Validation, Edit Validate & WCAG Accessibility 6.4 Form Views: Default vs Hierarchical Forms, Field Groups & Primary Fields
7 Chapter 7: Rule Architecture & Rule Resolution
7.1 Rulesets, Versioning & Ruleset Stack Hierarchy 7.2 The Rule Resolution Algorithm 7.3 Circumstancing & Rule Specialization
8 Chapter 8: Security & Access Control
8.1 Authentication, Operator Records & Access Groups 8.2 Role-Based Access Control: Access Roles, ARO & Privileges 8.3 Attribute-Based Access Control (ABAC), Encryption & Audit Trails 8.4 The Security Checklist & Secure Deployment
9 Chapter 9: DevOps, Testing & Application Quality
9.1 Guardrail Compliance, Best Practices & Performance Profiling 9.2 Automated Testing: Pega Unit Test Cases & Scenario Testing 9.3 Packaging, Branching & Deployment Manager CI/CD
10 Chapter 10: Reporting & Operational Analytics
10.1 Report Definitions: Querying, Columns, Summaries & Joins 10.2 Filtering, Parameters & Column Exposure Optimization 10.3 Insights, Visual Dashboards & Business Metrics
11 Chapter 11: Mobility, Digital Channels & Portals
11.1 Mobile Channel Configuration & Offline Processing 11.2 Web Mashup, Digital Channels & Constellation Embed 11.3 Channels, Personas, Portals & Landing Pages
12 Chapter 12: Center-out Architecture, Enterprise Reuse & Agile Delivery
12.1 Center-out Business Architecture & the Case for Pega 12.2 The Situational Layer Cake, Modules & Enterprise Reuse 12.3 Agile Workbench, Workspaces, Branches, Delivery Roles & the Estimator
13 Chapter 13: Pega GenAI for System Architects
13.1 Pega Blueprint: Creating, Importing & Modifying an Application Design 13.2 Pega GenAI Autopilot & Pega GenAI Coach 13.3 Pega GenAI Connect Rules, Knowledge Buddy, Agents & Tool Rules
3.1 Multi-Step Processes, Parallel Processing & Sub-processes
Key Takeaways Explain This Topic AI
Sequential processes execute in linear order within a stage, whereas parallel processes start concurrently upon stage entry to expedite multi-departmental or multi-task operations.
The Split Join shape spawns two or more distinct flow rules simultaneously and synchronizes them using Join conditions: All, Any, or Some (When condition).
The Split For Each shape iterates over a Page List or Page Group, executing a designated sub-process concurrently for each element in the collection.
Default pessimistic locking places an exclusive lock on the case, creating severe contention during parallel processing; optimistic locking resolves this by postponing lock acquisition until database commit.
The Spin-off flow option on a Sub-process shape initiates an asynchronous, independent thread of execution that does not block the main process from continuing.
Last updated: September 2026
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:
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.
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:
Join Condition Operational Behavior Common Business Use Case
All The calling flow pauses until every spawned sub-process reaches an End shape. Strict dual-authorization, such as requiring both Financial Underwriting and Legal Compliance to complete before issuing a contract.
Any The calling flow advances as soon as the first sub-process reaches an End shape. Pega provides an option to cancel remaining open sub-processes. Competitive quote gathering or emergency dispatch, where the first available vendor or responder completes the requirement.
Some The calling flow evaluates a When condition rule or count each time any sub-process completes. If the condition evaluates to true, the flow proceeds immediately. Quorum approvals, such as proceeding once two out of three regional directors have approved a budget request.
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.
- Feature Default Locking (Pessimistic) Optimistic Locking
- Lock Acquisition Immediately upon opening an assignment Momentarily during submission/save
- Concurrent Editors Exactly one user/thread Multiple users/threads
- Lock Collisions Frequent in parallel workflows; blocks users None upon open; managed at submission
Best Used For Linear, single-user workflows with rapid completion Multi-user parallel processes, Split Join, Split For Each