CPR State Reset
Overview
This feature allows clients to reset the state of an application on the CPR backend, either completely or from a specific module, directly from the application details page in Case Management. It helps unblock users by restoring the application to a desired starting point.
Demo
Purpose & use case
This feature aims to solve the following problems:
- Allows admins of a client to reset the user journey to a desired point.
- Can be used to unblock users who are stuck at a particular point and need to restart from a previous step.
- Example: a user's selfie was accepted and they got auto-approved by HV but were rejected by KRA, and the client wants the user to restart from the selfie step. Due to CPR, the user won't be able to restart the journey if exit on end states is configured. This feature helps clients unblock their users.
Deep dive
Two types of resets are supported:
- Reset from the beginning — clears the entire state record on CPR; the user is asked to restart from the beginning.
- Reset from a particular module — clears the state for all modules from the selected module onwards.
- Users see a list of modules used in the journey as per the module execution order.
- For super modules, the constituent modules are clubbed and shown as a single option; selecting this option lets the user restart the journey from the first module of the super module.
- API modules are not displayed in the list.
This action is irreversible — state once reset deletes the data as per the option selected and it is not possible to recover the state.
Who will be allowed to reset the state?
Only admins can reset the state for applications. Users with any other role cannot reset the state.
When can the state be reset?
- Whenever the user starts and the application has not been reset.
- Whenever the user reaches an end state after a reset.
When can the state not be reset?
- If the state was previously reset and the user starts the journey again after that.
- The users on case management will not see the option to reset the state if they reset the state for an application and then the user restarts the journey.
- We wait for the user to reach an end state before resurfacing this option.
Is this feature enabled by default?
No, it is not enabled by default. It needs to be enabled on the workflow config.
How can I enable the feature for a workflow?
Modify the workflow config:
- Open the workflow config.
- Navigate to
properties.serverSideResume. - Add a new key
dashboardStateResetof type object. - Add
enabled: true.
Sample config:
"serverSideResume": {
"enable": true,
"exitOnEndStates": ["auto_approved", "needs_review", "manually_approved"],
"dashboardStateReset": {
"enabled": true
}
}
- Raise an MR and get it merged.
- It can take up to a maximum of 15 minutes for the change to be reflected.
FAQs
Q: Is it enabled by default? A: No, it has to be enabled by updating the workflow config.
Q: Can reviewers or auditors reset the state? A: No, only admins are allowed to reset the state.
Q: Client accidentally reset the state — how do we reverse this? A: This is an irreversible action — we cannot recover the data once reset.
Q: Do we log which user has reset the journey along with the option they selected? A: Yes, this is logged. It is stored in Audit Logs, currently only available on Metabase.
Q: How do we send this reset information to the client systems via webhook? A: As of 29 May 2025, we do not trigger a webhook to the client. This is planned for phase 2.