Cases
A case is created each time you start a process and represents the workflow routing for a single instance of that process. You can start a case for a process if you are designated as the requester. Additionally, you can participate in cases started by others if you are assigned as a task assignee in any task within the process.
Requests
If a case triggers another process through a signal, data connector, sub-process, or PM Block, these are grouped as requests within the same case. Bundling requests into cases ensures efficient analysis of business processes and prevents related requests from being counted multiple times.
For simple workflows, one case typically corresponds to a single request. Complex workflows involving sub-processes or additional elements may have multiple requests associated with a single case.
This structure offers a holistic view of process analytics, particularly for workflows with sub-processes or advanced components.
Case Creation and Propagation
Case Initialization
When a user starts a process, a unique case number is assigned to it. This case number is carried forward to subsequent requests (if any) triggered by the parent process, ensuring they remain part of the same logical workflow.
A case can be started in the following ways:
Clicking the +Case button
in the top-right corner of the platform.From the Start New Case section in the Participant Welcome Screen.
Using the Start This Process button from the Process Launchpad.
Triggering a Start Timer Event or Conditional Start Event element.
Accessing the process via a Web Entry link.
Requests within a Case
Additional requests triggered through subprocesses, data connectors, PM Blocks, or signals inherit the original case number. This prevents these requests from being counted as separate cases, keeping them logically tied to the same workflow.
In the following scenarios, a new case is not created; instead, a request is added to the existing case:
Sub-processes: Requests initiated by a sub-process from a parent request are part of the parent case.
Data Connectors or PM Blocks: Requests triggered by these elements from a parent request remain within the parent case.
Signal Start Events: Requests triggered by a signal start event from another process are added to the originating case.
By maintaining logical grouping through cases, this system enables a clear and organized view of workflows, even in complex processes. Watch the following product tour to learn how cases and requests are created.
Case Management
Watch the following product tour to learn how to manage your cases.
Use Case Examples
Consider a process like Leave of Absence. A case in this context would represent the entire process of requesting, reviewing, and approving one leave of absence. If the process is simple and does not involve any sub-processes or calls to another process, then one case of the process will have just one request in it. On the other hand, if the process calls a sub-process, a single case will encompass two or more requests.
Similarly, for a process like Account Opening, a case would encompass the application, review, and creating new bank account requests. Even if these requests are mapped across multiple process models (e.g., request, review, communication), they share the same case as they pertain to the same applicant and account.
How accurate is the case counter? The accuracy of the case counter is ensured through various mechanisms that track any request that is not initiated by another request. Each request is carefully evaluated to maintain accurate case tracking.
Is there a limit to how many subprocesses count towards a case? No, as long as they are all initiated as part of the same parent process.
Why is there an "+Case" button now instead of "+Request"? The "+Case" button replaces "+Request" to better align with the enhanced case tracking feature. The functionality does not change.
Can I limit case consumption for users? No, this limit can't be defined.
How can I trust the data provided? In the Analytics tab, you can view the number of cases used by each process every month. Track the performance of processes to ensure they are used as expected so you can make adjustments as needed in real time. In contract reviews between Customer Success Managers and clients, both sides will be using the same case count so there are no surprises.
How does this change affect the transition from PM3 to PM4? This will not impact transitions from PM3 to PM4.
Why are you introducing Cases in addition to Requests? The case counter feature is aimed at enhancing the analysis of business processes. Tracking cases provides an accurate representation of Platform usage. Clients can see for themselves how much a process is used. By tracking cases in this way, process designers are encouraged to follow best practices, including the use of PM Blocks, sub-processes, and other features that generate additional requests beyond the initial parent request. Clients will not be penalized for having processes that have any number of sub-processes or other elements. What happens if I use more or less than my purchased cases? You will not be penalized or capped for going over the expected number of cases for the year. CSMs will work with clients to fit contracts to the reasonably expected number of cases per month for the length of the upcoming contract terms. Each year - or as needed - CSMs and clients will review past usage and upcoming expected use to adjust for the next contract term.
Who do I contact if I disagree with the case count? If there are disagreements with the case count, please reach out to our support team. They will assist in investigating and resolving any discrepancies to ensure accurate tracking.
Configure Case Title
The title of a case can be customized to display relevant information about the case. Watch the following product tour to learn how to configure a case title or click here for more information.