We have a requirement related to case navigation and stage/step movement.
Scenario:
In an assignment, we have a radio button with two options:
Move the case to the previous stage – This can be achieved using the standard Change Stage smart shape and is straightforward.
Move the case to a specific step in the previous stage – We need guidance on how to achieve this requirement.
Question:
What is the recommended approach in Pega to move a case from the current stage to a specific step/process within a previous stage, instead of simply changing the stage?
Any suggestions or best practices would be appreciated.
Moving a case back to a specific process or step within a previous stage can be achieved using a combination of the Change Stage smart shape and conditional routing.
Depending on whether you need to jump to a specific process or a specific step, here are the best approaches:
1. Process-Level Routing (Using Start Conditions)
If you just want to skip the initial processes of the previous stage and land on a specific process:
Set a Flag: Before executing the Change Stage shape, set a property/flag (e.g., IsJumpBack = true).
Configure Start Conditions: In the previous stage’s configuration, set conditions on the early processes to skip them if IsJumpBack is true. This will cause Pega to automatically skip straight to your target process.
2. Step-Level Routing (Using a Decision Shape)
If you need to bypass specific steps inside a process:
Place a Decision Shape immediately after the Start shape of that process.
Evaluate your jump flag. If it evaluates to true, route the connector line directly to the specific step you want to execute, completely bypassing the preceding steps.
3. Tickets (Not Recommended)
While you can technically use Tickets to jump directly to a specific assignment in a flow, this approach is largely deprecated in modern Pega versions and is not recommended for clean case management design.
Before implementing a backward stage jump, it is highly recommended to evaluate why the user needs to go back:
If the user just needs to correct, edit, or review details submitted in an earlier stage, consider using an Optional Action (Local Action) or an Optional Process instead.
Changing stages backward resets the case lifecycle path and can complicate audit trails or reporting. Optional actions allow users to update data ad-hoc without breaking the forward momentum of the case.
The last paragraph in this response is the most important.. so thank you for well rounded considerations. As said precisely, i would first establish why is this needed and implement it via Optional (local) action / process to keep my stage / step SLA’s intact. remember under the covers there are SLA’s being monitored and jumping like what described in the original problem can jeopardies the SLA values if those are relied on in the solution currently or in the future.
Also for argument sake if you implement the jump back to previous step.. what happens after that step is complete? will it be appropriate for journey to re-present the steps completed or should it come back to where it was when switch happened? what if the interim steps were routed to different team / workgroup? are they expected to perform action again ? what about their SLA’s and workload for expecting them to redo the work.
All these are contextual considerations and hence rather than HOW first think about why, to achieve what and at what cost / implications.
I agree with @Amey_Thombre. While this approach is technically feasible for navigating between stages, it is important to carefully consider the implications of moving across stages without following the defined case lifecycle.
Jumping directly between stages or steps can bypass intended workflow logic, potentially impacting data consistency, auditability, and overall case integrity. It’s recommended to evaluate whether the requirement can be addressed through alternative patterns such as optional actions or controlled process routing that preserve the lifecycle design.