Problem Description:
If you create a new document using Office client applications (such as Word, Excel, PowerPoint) and save it into SharePoint, event receivers do not fire.
Common belief: This is because “adds from Office only fire ItemAdded, not ItemUpdated”. (Please note that this statement is not correct.)
Correction: Adds from Office client applications fire all registered event receivers at all times. However, since they fire with security context of triggering user (normal users), most of the time that user has no admin rights to perform operations such as creating subsite, modifying site, web objects, sending email … etc. This makes users think that event receivers do not fire.
Here are all item events:
- ItemAdded
- ItemAdding
- ItemAttachmentAdded
- ItemAttachmentAdding
- ItemAttachmentDeleted
- ItemAttachmentDeleting
- ItemCheckedIn
- ItemCheckedOut
- ItemCheckingIn
- ItemCheckingOut
- ItemDeleted
- ItemDeleting
- ItemFileConverted
- ItemFileMoved
- ItemFileMoving
- ItemUncheckedOut
- ItemUncheckingOut
- ItemUpdated
- ItemUpdating
Let’s take a look at the sequence event are fired.
While uploading a new document in SharePoint library:
Case-1: If a document library does not force check-out, here is the sequence of item events fired.

Case-2: If a document library forces check-out, here is the sequence of item events fired.

Note: ‘..ing’ events are sync before-events. ‘…ed’ events are asynch after-events.
While creating a new document using Office client applications:
(such as Word, Excel, PowerPoint)
Case-1: If a document library does not force check-out, here is the sequence of item events fired.

Case-2: If a document library forces check-out, here is the sequence of item events fired.

Demo:
Let’s deep dive into the issue:
“Event Receiver not firing while adding a document using Office client applications”
In this demo, I’ll have a code snippet to update current web’s description each time an event fires as seen below.

Doing so, not only we get to see which events fire but also we’ll observe the sequence they fire. Remember before-events are sync events, however after-events are asynch events. This means that execution sequence of after-events may vary with different executions of same code.
Usage-1: No Try-Catch, opening web object from event properties object

Create a new document

Type something and save it

Debug and put a breakpoint at web.Update().

Go ahead and execute this line, you’ll see that an exception is thrown.

Important Finding:
Reason we get a security exception here is that event receiver’s ‘properties’ object was created using current user who has no privileges to update web object.
Misleading fact:
Since there is no exception handling here, thrown exception is not caught by event receiver code. Execution continues and end-user gets no exception, which makes end-user think event receiver is not firing.
What to do:
Always use exception handling in your event receiver code. Handle any exceptions thrown accordingly.
Usage-2: Using Try-Catch, opening web object from event properties object

Follow same steps above to create a test doc. This time we’ll catch the exception.

Now, we are aware that something went wrong. It’s an “Access Denied” error, due to security context of current user. Current user has no rights to modify web object, which is normal behavior to expect.
Usage-3: Using Try-Catch, opening web object from event properties object, and running code with elevated privileges
This time let’s try to run the code with elevated privileges to solve security context problem.

Again, create another test document and debug.

Now, we see here something really interesting:
Access Denied error while running with Elevated Privileges!!!
Important Finding:
Even though code is run with elevated privileges, we still get a security exception. This is because event receiver’s ‘properties’ object is still created using current user’s security context.
Misleading fact:
Running code with elevated privileges does NOT always guarantee that you will not get an “Access Denied” error. Security context of objects are still to be checked even though your code executes with elevated privileges.
What to do:
Always use ‘Using’ clauses when running your code with Elevated Privileges in order to avoid security related exceptions.
Usage-4: Using Try-Catch, opening web object using ‘Using’ clauses, and running code with elevated privileges
Finally, let’s add using clauses to the code. Doing so, we ensure that a brand new web object is created while running code with elevated privileges.

Create another test document and debug.

As seen above, this time web.Update() method is executed successfully!
Also, web description has been updated.

zieglers