Digital Process Automation
Model the case, then the work
Pega process automation is built around a case type whose lifecycle is divided into stages. Each stage contains one or more processes, and each process contains steps made of shapes such as assignments, data transforms, decisions, utilities, and subprocesses. Keep this hierarchy straight: stages do not sit inside processes; processes sit inside stages. A subcase is a separate case instance created by a parent case, useful when work has its own lifecycle, SLA, or audit trail. Do not confuse a subcase with a subprocess, which is simply reusable logic inside the parent case.
Routing, timing, and automation
Assignments route work to users, workbaskets, or work queues. Service levels can be attached at assignment, process, stage, or case level to track goals and deadlines. Urgency affects worklist ordering, while SLA events drive escalation. Decision rules, when rules, and data transforms remove manual steps; use them when the outcome is deterministic and testable.
Traps candidates miss
Questions often test whether a requirement needs parallel processing, optional processing, or dependency. Parallel processes in a stage can run at the same time, but if one process must wait for another to finish, model that dependency explicitly rather than assuming order. Another trap is treating a step as an assignment: a step is a container; the assignment is the shape that creates a task. Also verify whether a requirement is case-wide or stage-specific before adding logic.
Worked rule of thumb
If a credit check must finish before shipping can start, make the credit check a subcase or an explicit dependency, not a sibling parallel process. If the check is optional and can be skipped, an optional process or conditional stage is usually cleaner.