I have an item receiver that implements ItemUpdated() to process an item after it has been uploaded to a document library. Everything works fine if I add documents to the default "Shared Documents" library - when a new document is added, ItemUpdated() is triggered normally. However, if I create a new document library in the same site collection, ItemUpdated() is not triggered when I upload a new document to it. But when I upload another version, or rename the document etc., ItemUpdated() is triggered normally - it's just not triggered on item upload. Typical example:

  • I upload 'doc1' to document library - ItemUpdated() doesn't execute (but it does execute if the document library is "Shared Documents");
  • I upload another version of 'doc1' - ItemUpdated() executes as expected;
  • I rename 'doc1' - ItemUpdated() executes as expected.

I was lead to believe that the order of events when adding a document is normally:

adding - added - updating - updated

So why is my ItemUpdated() not getting triggered for libraries other than "Shared Documents"? Is there some setting that may be causing this?

Note that for various reasons, I cannot do the processing inside ItemAdded().


<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers ListTemplateId="101">


public class MyEventReceiver : SPItemEventReceiver
    // On document upload, this method is only entered if I upload to "Shared Documents"
    public override void ItemUpdated(SPItemEventProperties properties)
        base.ItemUpdated(properties); // doesn't get called either
  • Can you please share your ItemUpdated code / Elements.XML file May 14, 2014 at 12:27

2 Answers 2


Do you have additional columns in one library or another? It seems that makes a difference in terms of whether ItemUpdating() fires on upload. Have a look at this post. The key sentence there is,

"the events that are triggered during when a document is Added to a Document Library MAY include ItemUpdating and ItemUpdated. But only if there are additional fields included in the process."

So you might want to play around with different library configurations in your environment so you can better understand how this "feature" of SharePoint impacts your system.

Also, I can appreciate that there may be reasons to avoid ItemAdded. If ItemUpdated continues to be an issue for you, and you'd be willing to share some detail about why ItemAdded is undesirable in your environment, consider asking a separate question here about how to make ItemAdded work in your system.

Good luck!


It seems I have found a solution. I implemented ItemAdded() besides the original ItemUpdated() in the event receiver. Inside, I force a subsequent call to ItemUpdated() like this:

public override void ItemAdded(SPItemEventProperties properties)

Note that UpdateOverwriteVersion "updates the item without creating another version of the item" (MSDN). This results in a call to ItemUpdated() when a new item is added; in addition, it doesn't create a new version of the item (i.e. you don't end up with 2 versions when you first add a new item). So far, this works as expected for all document libraries, with and without versioning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.