A stage is the first level of organizing work in your case type. It contains the tasks, or steps, that users perform before they can move a case to the next phase in its life cycle. Behind the scenes, your application uses flows, service-level agreements, when conditions, and other rules to make the progression through each stage and step seamless.
Capturing business requirements in stages helps you get a sense of what you need to do first, what must happen in sequence, and what can happen in parallel. Stages are reusable, easy to refactor, and realistically model the actions that users take when they process a case.
Tip: Use three to nine stages in a case type.
Use Case Designer to view the stages and steps in your case type.
The last stage in the sequence is typically a resolution stage. When you complete all steps in this stage, the case is closed. You cannot update the case again without manually reopening it. Resolution stages use a red underline to visually indicate they resolve a case.
Relevant steps are displayed below their corresponding stage.
You can use transitions to further refine the run-time order of stages. Stage transitions allow you to build robust logic that closely matches your business requirements into your application.
The following transitions are supported at the stage level:
Automatic — Moves the case to the next stage in the sequence, after all steps
Manual — Waits for the caseworker to determine the next stage for the case to enter.
Resolve — Ends processing and does not allow the case to enter any subsequent stages.
In addition, you can specify conditions that must be met before a stage is entered or skipped, such as the value of a property or the type of attachments added to the case. Using entrance criteria and validation helps users avoid errors and process cases completely.