I am finishing up with my current employer and, in the process, finishing what has been a really interesting project using Dynamics CRM for Case management. The project forced me to learn about new CRM features like routing rules and email conversion as well as Parature integration; all of which will prove rich sources of inspiration for future articles.
In this article I will go through a bit of configuration I set up to track the movements of a Case.
Business Context
In our scenario, the client wanted to see if a Case bounced around the different areas of the business or not. To do this, they wanted a log of where the Case had been and for how long. In our situation I was using Teams instead of Queues as the client wanted the areas of the business to take responsibility (ownership) for the Cases assigned to them. Teams lent themselves nicely to this.
Setting up the Case Audit
The first step was creating a new entity to hold the history of the Case movement. I called this the Case Audit. The fields it had were:
- Description: The default Name field for the entity
- Created On: A date field
- Previously Assigned: When the Case had been moved previously
- Owner: A Team or User
- Case Status: The Status Reason of the Case
- Hours in Queue: Time with a particular Owner
This was a child entity to the Case. In the above example, the Case moved from being created by Ranjeet at 12:28pm to the Records (transcript) team to being picked up by me for actioning. You may notice that I am exploiting the Owner of the Case Audit to track ownership of the Case.
Creating the entity was straightforward, populating it was a little trickier.
Populating the Case Audit Log
To populate the log, I used a real time workflow.
Looking at when the process runs, it runs:
- After the record is created (creating the first entry in the log)
- Before the status changes
- Before the record is assigned
- Before fields change (Owner, Status, and Status Reason)
Then, when it fires, it firstly checks if the Case is Cancelled or Resolved (the act of trying to create a log entry on a closed Case was preventing the Case from being reopened so this got around that).
Assuming the Case is active, it then creates a Case Audit record to mark the change and changes the Last Assigned Time on the Case (a custom field).
The values for the Case Audit were:
The Name field gets populated with sensible values to assist with queries. The Previously Assigned takes the date time value from the Case record, just before it is updated in the next step by this workflow. The Owner of the Audit record is set to the Owner of the Case (meaning we can store a Team or a User), and the Case Status simply takes the Status Reason of the Case. Finally, the Hours in Queue is a calculated decimal field.
The reason I used DiffInMinutes and divided by 60, rather than DiffInHours is because the Diff functions return an integer, which for quick owner transfers simply was not accurate enough. By using minutes I could track the movement in hours but with two decimal places.
So, with this workflow, I got a new entry every time the record changed status (except when re-opening because of the error, which could be worked around with a second workflow, if required) and every time it was assigned to a Team or User.
Charts and Measures Available
With this in place and a few other tricks, a wealth of measures are now available. Firstly, using my record-level graphs trick, on the Case record it is possible to see the history of the Case and how long it had been with each Owner.
While the graph is only for one day in the above example, if the Case remained open across multiple days this would also be reflected in the above graph. On the Case, we have the following measures.
The Initial Queue, Latest Queue, Moved Off Queue (when someone took ownership), and Queue Hops (how many Teams the Case has been to) are populated by a second workflow running after the change in ownership. The Hours in Queue measures how long the Case bounced around teams before being owned by a user and is a calculated field using the Case Created On field and the Moved Off Queue. The Hours To Resolve is a calculated field using the Moved Off Queue and the Modified On field which only populates if the Case is resolved (calculated fields can be conditional).
Non-Working Hours is a rollup field, looking at the Case Audit entries and summing up the Hours in Queue values for entries with a status other than In Progress (rollup fields can be conditional). Finally, the Last Audit Entry is the field populated by our workflow and used to generate the next Case Audit record.
With all these in place, we can also generate charts such as the average hours Cases stay with a Team and the average time for resolution.
Conclusion
With some of the newer tools of Dynamics CRM such as calculated fields, rollup fields and real time workflows, we can provide insight into our CRM data without resorting to BI tools or exporting to Excel, giving instant feedback to the business. If you have not yet played with these new features, I strongly recommend giving them a try.