System update for SharePoint list items using App model

One of the often discussed requirements for app model is the need for updating list items without impacting the Modified By or Modified date of the item. In server side code this was done using SystemUpdate method, but we don’t have similar method as such available for app model using remote operations (CSOM or REST).

What we can do though is to manipulate Modified By and Modified date directly if needed with the right permissions. You can actually also change the Created By and Created date, if needed for example for content migration purposes, if you have the right permissions.

In short this means that you can do for example following for changing the columns of the list item.

   1: ListItem item = list.GetItemById(1);
   2: ctx.Load(item);
   3: ctx.ExecuteQuery();
   5: User user = web.EnsureUser("i:0#.f|membership|");
   6: ctx.Load(user);
   7: ctx.ExecuteQuery();
   9: item["Modified"] = DateTime.Now.AddYears(-5);
  10: item["Created"] = DateTime.Now.AddYears(-5);
  11: item["Editor"] = user.Id;
  12: item["Author"] = user.Id;
  13: item.Update();
  14: ctx.ExecuteQuery();

Wait wait wait!Wouldn’t that actually expose possibility to change the item permission or the metadata of the item? Not precisely. This does not impact the permission of the item and we need to remember that when the used the SystemUpdate with proper permissions, this was precisely what we were able to do as well. Key point here is the needed permissions, since this capability is not available for all users or accounts with edit permissions.

Identity used for this kind of operation for overriding the item metadata will have to have at least “Manage Permissions” permission to the site before the update can be done. Person with “contributor” right can override only the modified information, but nothing else. This means that you will need to be basically administrator for applying these kind of updates for the items in the sites.

From auditing perspective this update will be also stored to the auditing logs, which cannot be modified. Auditing logs should be considered as the final version of the truth, not the item data in the SharePoint lists and you can’t override those events.

This is again one of those good snippets to keep in your tool belt when you start transforming your server side code to the new app model or when you need to apply these settings remotely in general.

Comments (9)
  1. john lowe says:

    This is great, thanks

  2. Ad van den Berg - CTB xRM says:

    A big advantage of the SystemUpdate in server side code is that there's no new version created of the document itself. Be aware that in this example a new version is created of the document.

  3. Steve Dawkins says:

    Tried this and Created By will override by Modified by won't when executing against SharePoint online.

  4. Vesa Juvonen says:

    Hi Steven,

    I just tested this with the following code without any issues. You must have run into permission level issues. Below code works just fine with tenant admin permissions (admin used for the SharePointOnlineCredentials). Did not have time to test with any other permissions. If you have any other questions, would suggest to use the Office 365 Developer Patterns and Practices Yammer group at for faster response.

               // Get access to source site

               using (var ctx = new ClientContext(""))


                   //Provide count and pwd for connecting to the source

                   var passWord = new SecureString();

                   foreach (char c in pwd.ToCharArray()) passWord.AppendChar(c);

                   ctx.Credentials = new SharePointOnlineCredentials("", passWord);

                   Web web = ctx.Web;



                   ListCollection lists = web.Lists;

                   List list = lists.GetByTitle("Test");

                   // Actual code for operations

                   ListItem item = list.GetItemById(1);





                   User user = web.EnsureUser("i:0#.f|membership|");



                   item["Modified"] = DateTime.Now.AddYears(-5);

                   item["Created"] = DateTime.Now.AddYears(-5);

                   item["Editor"] = user.Id;

                   item["Author"] = user.Id;




  5. TRGermain says:

    I'm looking for SystemUpdate so I can update a list item from a SharePoint 2013 workflow without triggering another workflow instance. I've used a "status" field to be able to terminate a new workflow instance for items that aren't new, but it's kind of a hack. I'd rather have the ability to do a SystemUpdate to prevent another workflow on change from firing.

  6. Crapass API says:

    This is meaningless.

    That doesn't replace system update at all.

    If i have 2.0 of a published document, and need to change modified by, This solution will give me

    a new version 2.1 and make the item draft.

    Then what, publish again ? Erasing the modified by ?

    CheckOut / CheckIn with overwrite almost works for drafts, created, created by, modified by is updated correctly, but not modified by.

    But that doesn't work for Major version, it is not allowed.

    Jesus what a crap ass API. Microsoft keeps pushins USE THE CLIENT API.

    Which is pretty much USELESS even after all these years.

    I have been trying to use the Client API for my last 3 clients, it always ends up with a farm solution

    in addition because the API is crap / limited.

    Microsoft are idiots, the product is dying and hopefully it will.

    Crossing my fingers.

  7. Vesa Juvonen says:

    Hi Crapass API,

    Thanks for you feedback. This is indeed not exactly the same as classic server side system update. Would though suggest to use official feedback channels rather than comments in blog posts. Best way to get your requests processed officially would be using Premier support or user voice at

  8. +1 says:

    +1 for @Crapass API. This definitely reflects my own thoughts on the whole App-Client-Coud model. I've been working with SP for 10 years, and for sure, you canno't develop any serious app with this client model.

Comments are closed.

Skip to main content