FAQ: Why do I keep getting an error saying that the object has been changed by another user or process?

August 16, 2012 Posted by Anders Asp

You have all seen it, in Service Manager 2010 and in Service Manager 2012, the error message that looks like this:

This error occurs when someone tries to update an object which has been updated by someone or something else since you initially loaded it – just as the error message itself states.

For example, a person named Carl opens an existing incident with ID IR1337, he then goes to grab a cup of coffee. While Carl is away getting coffee, another person, Stefan, opens the same incident, IR1337, and add a comment to the Action log of it. When Carl gets back to his computer to work with IR1337, he is actually sitting with an outdated version of the incident. If he make any change to this incident and then tries to save the changes by pressing Apply or Ok, the error message above will be displayed.

Now, this error appears more frequently in Service Manager 2012 and the reason for that is a new internal workflow that sets the First Assigned Date. The First Assigned Date property was added to work items so you can build Metrics and construct SLOs around the time it takes to assign the work item to someone.

So if we don’t use First Assigned date for anything, we are better of turning this workflow of in order to decrease the frequency of the error above.

How do we do this? Take a look at this blogpost written by Travis that describes how to turn of workflows with overrides:

Use the SQL queries in the blogpost to get all the nescessary information and create a management pack. For those a bit lazy, here’s the complete XML code needed. The entire MP is also attached at the bottom this post.

<ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <Reference Alias="EnterpriseManagement">
	  <Reference Alias="SMIncidentLib">
	  <Reference Alias="Administration">
    <Category ID="Category.af8135f310fc4c3190a2544c8f514476" Value="EnterpriseManagement!Microsoft.EnterpriseManagement.ServiceManager.ManagementPack">
  <RulePropertyOverride ID="Override_WorkItem_SetFirstAssingedTo_RelationhsipAdd_Rule" Context="SMIncidentLib!System.WorkItem.Incident.WorkflowTarget" Enforced="false" Property="Enabled" Rule="SMIncidentLib!WorkItem_SetFirstAssingedTo_RelationhsipAdd_Rule"> <Value>false</Value> </RulePropertyOverride>
    <LanguagePack ID="ENU" IsDefault="true">
        <DisplayString ElementID="FirstAssignedDateOverride">
          <Description />

Download the complete MP here:

13 Responses to FAQ: Why do I keep getting an error saying that the object has been changed by another user or process?

  1. Andy S says:

    This is an issue I’m faced with, however I need the First Assigned date for SLA metrics.

    I get the basic architecture and how workflows run periodically behind the scenes to drive incident management, but there must be a better way to handle these types situations. If I decrease the poll period (assuming I can for First Assigned workflow) I could be potentially increasing an undesirable overhead on the management server / database.

    Any suggestions for those that require the First Assigned date?

  2. Anders Asp says:

    Hi Andy,

    If you want the First Assigned Date to be added automatically you will need a workflow to do so. Regardless of how you configure this workflow it will cause issues like this – it’s a limitation in the current version of SCSM. If Microsoft could make sure that this applies to a property level instead of an object level, these errors would reduce drasticly!

    From the top of my head, the best option for you would be:
    – Set the First Assigned Date manually (this could ofcourse lead to people missing to set it…)
    – Teach your analysts to NOT use that Apply button! The workflow won’t trigger unless the Work Item is commited to the database.

  3. Rob Ford says:

    Oh, look! Another Microsoft typo 😛


  4. Pingback: SCSM - The item cannot be updated.....aka. Click Apply and die :-) - Thomas Ellermanns view on System Center - Site Home - TechNet Blogs

  5. Heikki Kanerva says:


    We would need this override also to Service Requests.

  6. Greg says:

    Is there a fix for this in the latest R2 update?

  7. Mario says:

    hi Anders,

    I imported the MP and when I run the SQL query to view workflows that are behind I see a bunch of Set First Response Date Rule that are behind. Is this normal?


    • Anders Asp says:

      Hi Mario,

      Yes, this is expected behaviour. Since we have disabled the workflows they should fall behind – otherwise they would still set the First Assigned Date.

  8. James says:

    I receive this error when attempting to create a windows computer CI. No matter how many times I re-launch the console I receive this error.

    Any thought?

  9. Paul says:

    Oh look another fantastic MS software product that has more holes than a teabag! what a surprise.

    Why do we constantly have to pay good money for a product with so many flaws, which when reported never get dealt with, so frustrating.

    Rant over…..

  10. Pingback: SCSM.SE » Blog Archive » Update Rollup 7 released – includes the write collision fix!

Leave a Reply to Greg Cancel reply

Your email address will not be published. Required fields are marked *