Modifying a case you don't own
Clarify employs a strict ownership paradigm with its application, meaning that only the owner of a workflow object can make a critical change to it. This ownership paradigm was baked into the product, and difficult to modify.
For example, anyone can add notes to a case, but only the owner can change the status.
What’s a critical change? Let’s take case as the object in question, and see what Clarify considers critical.
Critical changes:
- Change any attributes of the case (title, priority, severity, etc.)
- Change the status
- Perform a workflow action (Assign, Dispatch)
- Close the Case
- Change the contact, product, or contract for the case
- Relate the case to a solution
Non-Critical changes:
- Log Notes
- Log Email
- Log Phone Call
- Log Research
However, organizations don’t always want to follow these imposed rules.
For example, it’s not that uncommon to have a supervisor want to be able to change the status of a case, even though the case is owned by an agent.
Modifying a case you don’t own with the Clarify Classic Client
To accomplish this in Clarify, he supervisor would first Yank the case, which means the supervisor takes ownership, regardless of who owns the case or where it currently resides. The supervisor can then modify the case. Finally, the supervisor would have to assign it back to the agent who previously owned it (which would always place it back into the previous owners default WIPbin, regardless of what WIPbin it was in before). Or dispatch it back to a queue, if it was in a queue. Not necessarily the simplest workflow.
Using Temporary Yank to modify a case you don’t own
Early on, back when we were First Choice Software, we released a product called Temporary Yank (affectionately called TYank around here), that simplified the process. The supervisor would Temporarily Yank the case, which would allow her to modify the case. All the supervisor had to do was simply dismiss the case form, and the case was automatically returned back to the previous owner, in whatever WIPbin the previous owner had it in. If the case was in a queue, it was put back into the queue as well.
Modifying a case you don’t own with fcClient
I recently had a request to add Temporary Yank functionality to our agent web application(fcClient).
The story I was given:
We need Temporary Yank in fcClient.
I immediately pushed back. That’s a solution, not a need. Instead, I want to understand the business need. And implement the appropriate solution for the business need, instead of just mimicking functionality that was developed for a different platform with different challenges.
I created a story:
As a supervisor, I need to be able to modify a case I do not own so that I can assist the case owner as needed.
Notice that there’s nothing in my story about Temporary Yank. It’s a story. Not a solution. Temporary Yank was a fine solution to the story on the Clarify Classic Client, because of the limitations we had with the Clarify Client, specifically, the ownership paradigm was baked into the C code of the product, and extremely difficult to change. However, we don’t have those same limitations with fcClient. We have different challenges.
My solution for this business need within fcClient would be to simply allow a non-owner to modify the case. Because we ship source code for the case page, it’s easy to do. Simply modify the case web page. Currently, the code says that if the current user does not equal the case owner, then the case page is read-only. We’ll change that code so that it doesn’t make the page read only.
But, we probably don’t want to do this for everybody. This is where the "as a supervisor" part of the story comes in. Now we see how the story is just a placeholder for a conversation. As the conversation unfolded, we realize that we don’t want to hard-code supervisor, but we want to make this a privilege that someone has. We already have an extensible privilege class framework in place. I would add a new privilege, such as EditCaseWhenNotCaseOwner. This would now work like all of the other privileges that are managed from within Dovetail Admin. Then, in the case page, add a conditional so that if the current user has this privilege, the case will not be read-only.
There’s a few extra cases to consider, such as if the case is in a queue, or if the case is closed, but those are easy to add logic for.
As a note, when the supervisor modifies the case, an activity log is created, and it will clearly show that the supervisor was the person who made the change.
Perhaps a business rule cherry on top?
I would probably round out this functionality with a suggestion for a new business rule, which would notify the case owner if the case was modified by someone else.
Rule Name: Case Modification Notification
Object Type: Case
Start Event: Modify
Conditions: [Current Owner] != [Logger]
Notify: [Current Owner]
Message: [Object Type] [Object ID] has been modified by [Logger]
Repeat: No
So what have we accomplished?
We’ve outlined a solution that allows a user other than the case owner to modify a case (as long as they have been granted privileges to do so). And when this happens, notify the owner that it did. In addition, the users don’t have to do anything special. Just edit the case. If we had mimicked the TYank functionality, the supervisor would have had to TYank the case first. So not only have we accomplished the goal, but we’ve simplified the process. Hopefully you can see what a difference it makes when you look at the problem first, as opposed to starting with a solution.
