What is all the fuss about case status reason transition? Why is it that planning is important before enabling this new functionality in CRM 2013 Service Pack 1?
Case Status and Status Reason
In Dynamics CRM most system entities (as well as custom entities) have 2 tightly coupled option sets known as “status” (schema name “statecode”) and “status reason” (schema name “statuscode”) that define the status and status reason of an entity record at a given time.
The status and status reason of a case record in Dynamics CRM represent the current stage that a case record is at in a business, e.g. customer service support, process. For example, out of the box case record can have an “Active” status where its status reason (one of the following) provides a more granulate explanation of its stage in the service process:
- In progress
- On hold
- Waiting for Details
On the other hand, if a user deactivates a case, under the hood, the case’s status changes from “Active” to “Resolved”. The record becomes read-only and can only be set to one of the following OOB status reasons:
- Problem Solved
- Information Provided
Similarly, if a user reactivates a case and changes its status from “Resolved” back to “Active”, the user is free to choose any one of the “Active” status reasons: “In Progress”, “On Hold”, “Waiting For Details”, or “Researching”.
There is nothing to guide or restrict the user when selecting an appropriate status reason associated with a particular status for a case record.
Until CRM 2013 Service Pack 1.
Case Status Reason Transition
CRM 2013 Service Pack 1 introduces the ability to limit the set of available (next) status reasons that a user can choose based on the status reason that the case is currently set to. In this function you can now customise a set of valid status reason transitions based on the case’s current status reason.
For example, perhaps in your business process you have the following rules:
- A user can “Merge” cases at any time
- A case can only be “Canceled” if the prior status reason is one of “On Hold” or “Waiting For Details”
- A case can only be reactivated to “In Progress” only if its prior status reason is “Canceled”
- A case that is “On Hold” or “Waiting For Details” cannot be resolved to “Problem Solved” or “Information Provided” without going through “In Progress” or “Researching”.
While Service Pack 1 provides you the ability to restrict the status reason as stated above, it turns out that working out the valid transitions to set in CRM is not quite as simple as I thought.
From the OOB status and status reasons alone I ended up drawing up a “transition matrix” in Excel, block out those transitions which are not valid via OOB UI, then add in the additional restrictions given above.
Once you work out what this set of valid transitions are, open the case’s “status reason” field in the CRM solution and click on the “Edit Status Reason Transition” button on the menu bar:
Make your selection of valid status reason transitions and click “Ok”. Publish your changes in the solution.
If a user now tests the valid transition by trying to e.g. reactivate a case that has status reason “Merged”, CRM will now prompt the user with the following error message:
“Because of the status transition rules, you can’t activate the case from the current status. Contact your system administrator.”
If you decide to enable this status transition rule functionality for cases, it is important now to also test not just the valid transitions, but also invalid transitions. Some scenarios for testing might include:
- A case that has status reason “Information Provided” cannot be reactivated,
- A case that has status reason “In Progress” cannot be canceled,
- A case that has status reason “On Hold” cannot be resolved.
What Happens If Case Status Reason Is Changed By Another Process?
For example, what happens if a real-time workflow is set to change the status reason of a case that violates one of the status reason transition rules?
Let’s say we have a real-time workflow that is triggered when a case “In Progress” has its origin field changed to “Twitter”. The workflow is set to change the case’s status reason immediately from “In Progress” to “Cancel”. Notice this directly violates one of the valid transition rules listed above.
What will the user sees?
As soon as the workflow triggers, the status reason change is blocked by the pre-defined valid transition and the following error is displayed to the user …
“Because of the status transition rules, you can’t resolve a case in the current status. Change the case status, and then try resolving it, or contact your system administrator.”
So now we know that not only do we have to be careful of how we define the case transition rules, we also need to ensure that other processes such as workflows or plugins respect the same status reason transitions. Otherwise things will not work.