I’ve been delivering SCSM 2012 since it was first released, over three years ago. In that time, there have been a number of challenges presented with the tool to which it has been my job to overcome. Among them all, there has always been a single issue which has consistently arisen with every client I’ve ever worked with: the dreaded question, “why does Service Manager throw an error whenever I try and save this ticket?”
For those unfamiliar with this issue (which is to say, “those who haven’t used Service Manager”), this issue is the result of a data collision – put simply, the current user is unable to save the work item because, in the time between opening the form, entering changes, and clicking “apply”, the work item has been updated by another user or, more frequently, a workflow. The only way around the issue is to refresh the work item, losing all changes which have been entered, then re-enter the changes and save again. In a heavily automated environment (read: “an ideal ITSM implementation”), this issue can occur multiple times within the span of a single call with an end user – any time a workflow touches that work item, the analyst has to start over from the last place they managed to save. The goal is to prevent data loss through one user saving over another’s work, but the end result is a headache.
For organizations measuring service efficiency by the time spent between a ticket being opened and being marked resolved, a situation causing staff to repeatedly re-do work is not just a frustration, it is simply unacceptable.
That fact makes it more of a mystery how this “bug” has persisted so long – it has been present since all the way back in Service Manager 2010.
Given that scenario, you can picture how elated I was when the Service Manager team announced that they were planning to fix this bug in an upcoming update rollup. As this bug is one of the most visible pain points in the Service Manager experience, fixing it would have a large impact on the perception of the product from the users to the administrators. With the announcement of a pending fix released, all that was left was to countdown the days until the fix went live.
Fortunately for us all reading this today, the wait is no more! Microsoft has released the latest Update Rollup for System Center 2012 R2, UR7, within which the Service Manager component contains the long awaited fix!
The Service Manager team has posted a blog detailing the new behavior in place to avoid this problem (link). I recommend you read the full posting to get all the details, however I’ll summarize here:
- So long as a save does not attempt to modify a property which has already been modified by another user or process, no error will occur and the save will complete successfully.
- Should other fields be updated, Service Manager will notify the user after the save completes. The work item will also be auto-refreshed to display all of the current data.
- If a save does attempt to modify a property which has been already been modified by another user or process, a new version of the classic error will appear, now clearly stating which properties are causing the issue. The user can review the error and decide whether to abandon their changes or update the problematic properties to match the current CMDB values in order to save successfully.
Here’s an image of what the new exception looks like. Note the green box, showing the properties with issues and what the current CMDB values are.
With this fix now published, I can’t imagine any reason not to run the update through your change management process and get it deployed in your production environment as soon as possible. Update Rollup 7 is an essential component to a positive Service Manager experience, for this fix alone. The update also contains several other key fixes which will improve the experience with the product.
I want to thank the product team for getting this update out, and encourage everyone to get it in place as soon as your processes allow.
Here are some useful links: