The Create stage captures initial data before case processing starts, so that case creation experience across channels is more model-driven and intuitive. By understanding how the Create stage works, you can use it in a way that is the most efficient and appropriate for your business scenario.
What does the Create stage include?
The Create stage includes a default Create process with a multistep form. You can modify the stage to meet your business needs by adding processes and steps. For greater flexibility, you can also rename the Create stage and the Create process to unique names that fit your business scenario.
The following figure shows a Create stage that is renamed to Submission, which includes the default Create process renamed to Collect information, with a multistep form. The Create stage in the example also includes an additional Collect documents process with two automated steps:
The Create stage
When does the processing of cases with the Create stage start?
The system creates a new case in the database right after an end user of your application opens the screen that displays the Create stage. The Create stage is related only to case creation, and actual case processing starts when the case moves to the stage that is next after the Create stage.
What happens if a user abandons a case in the Create stage?
If a user abandons a case in the Create stage, for example, when a user navigates away from the browser tab with the case and the browser session ends, the abandoned case remains with the New status. If the user cancels the case, the case automatically moves to the Resolved-Cancelled status, and worklists and work queues omit the case to better facilitate workload management. Maintaining such cases in your system helps you analyze and understand the reasons why users might discard cases at an early stage. If you do not want to maintain cases with the Resolved-Cancelled status, create an appropriate archive and cleanup policy.
Can I configure a case type with the Create stage to be a temporary case at run time?
Cases that include the Create stage are persistent by default, which means that you cannot create a temporary case from a case type that includes the Create stage.
The following table shows differences between temporary cases and case types with the Create stage:
Case types with the Create stage | Temporary cases |
Information about how users interact with a case from the moment of case creation | No information about user interaction with a case before the case becomes persistent |
Support for all capabilities that are available for case types | No support for numerous capabilities, such as: audit trial attachments service-level agreements child case types routing assignments to specific users |
Persistent by default | Need to configure when the case becomes persistent |
Consequently, only case types with the Create stage provide all information about user interaction and support all available features.
If your business scenario absolutely requires creating temporary cases, you can create a temporary case on a case type rule form in Dev Studio. However, temporary cases are a deprecated feature and creating such cases in Pega Platform version 8.5 and later might have upgrade impact in the future.
How does the Create stage work with creating a case by email?
When creating a case by email, at run time, your application omits the default Create process. The purpose of the Create process is to capture the initial data that is required before submitting a case, but because an email starting a case meets the same requirement, the application skips the Create process.
Can I use the Create stage for different channels?
To reach wider audiences, you can create a channel-specific process inside the Create stage, for example, a process for users who interact with your application through a chat bot.
Do all my case types include the Create stage by default?
All case types that you create in Pega Platform version 8.5 and later have the Create stage by default. Case types that you migrate from Pega Platform version 8.4 and earlier do not include the Create stage. You can add the Create stage to your migrated case types to take advantage of all the possibilities that the Create stage offers.
Can I remove the Create stage from my case type?
The Create stage is a mandatory element for collecting information before a user submits a case, so you cannot remove the Create stage from a case life cycle.
Can I configure entry validation for the Create stage?
A case always enters the Create stage, so you do not need to configure entry validation. If you want to configure validations upon case creation, configure validations as part of the view for the first assignment in the Create stage.
If the Create stage in your business scenario includes no assignments, configure validation for the first stage after the Create stage.
Can I route an assignment in a Create stage to a work queue?
The main purpose of the Create stage is to collect initial data before case processing, so configure routing of the assignments in the Create stage to a current user. If your business scenario requires routing assignments to a work queue or a user different that a current user, configure routing logic on a stage that follows the Create stage.
Can I configure parallel processes in the Create stage?
Yes, you can configure parallel processes in the Create stage. As a best practice, configure your application to route parallel processes to a current user, because the purpose of the Create stage is to collect data before case processing begins.
What harness does the Create stage include?
The Create stage includes the pyCreate harness for assignments. Other stages in a case type include the Perform harness for assignments.
Can a user navigate back to the Create stage?
No, a case can only enter the Create stage once.
Does the Create stage include the starting process?
Case types that include the Create stage are independent of the pyStartCase or any other starting process during case creation. As a result, your application is more granular and easier to maintain because you do not provide the starting process when you configure various functionalities, such as email instantiation of cases. All the configuration that in the previous versions of Pega Platform corresponded to the pyStartCase process, you now configure on the Create stage.
Only case types that you migrate from Pega Platform version 8.4 or earlier and that do not include the Create stage rely on the starting process.
How can I pass parameters to a new case upon case creation if my case types are independent from the pyStartCase starting process?
You can still pass parameters when users create new case types by configuring the Create work action.
If my child case type includes the Create stage, how do parent and child case types interact?
When a child case starts from the parent case, the child case enters the Create stage and waits for the user interaction with the first assignment in the Create process, similarly to other case types with the Create stage. If your business scenario requires an application to skip the Create process in a child case, define conditions to start the Create process only under specific circumstances.
Can I start a case on the stage that follows the Create stage?
You can leave the Create stage unpopulated and start processing on the stage that follows the Create stage. However, your system still creates a new case when an end user interacts with the Create stage at run time. As a best practice, use the Create stage to collect initial data before case processing starts.
How does case creation occur when users create cases through V1 and V2 DX APIs?
A case always enters the Create stage upon case creation through any channel, also through DX APIs. For greater flexibility, you can use the pxCreateFromChannel field to conditionally start a specific process that you want to run within the Create stage. The default value of the pxCreateFromChannel field is Web. You can pass a different value as part of the X-Origin-Channel when you invoke the DX API.