Understanding Event Receivers in SharePoint

Event Receivers are functions that get triggered when a specific event occurs in SharePoint. By creating them, you can respond effectively to SharePoint lists and list items. In this post we’ll look at some best practices in working with them.

Event Receivers, Before Events & After Events

Event Receivers can be created at the following levels:

  • Site Collection (for deletion)
  • Web (for creation, URL modification, deletion)
  • List (creation, deletion, receiving emails)
  • Field/Column (creation, update, deletion)
  • Item (creation, update, deletion, check in/check out, file movement, file conversion, adding attachment, deleting attaching)
  • Workflow (start, postponed, completed level)

Before Events occur before an operation. For example, events like ItemAdding/ItemUpdating are Before Events triggered before the Item is actually added or updated to the SharePoint List. Typically, before events are performed for Data Validation, as methods are triggered even before List events are fired and SharePoint updates the Content Database. All the Before Events are synchronous events which are executed in the same thread that a triggering action occurs.

After Events occur after the operation runs and SharePoint finishes updating the content database. After events can be executed either synchronously or asynchronously. If it is synchronous it executes on the same thread as triggering action. If it is executed as asynchronous it gets executed in a separate thread.

Best Practices when Working with Event Receivers

Usually event receivers are created for list items. As such, it is good practice to name the List Fields without special characters. For example, the list name should be “MyColumnName” rather than “My Column Name”. This is because SharePoint uses two names for storing list fields/columns. The Display Name (the name that appears to users in UI) and the Internal Name. Because of this, if we called our list column “My Column Name”, the display name would be “My Column Name” whereas the Internal Name would be something like “My_x0020_Column _x0020_Name”.

In Event Receivers we have two options: Synchronous and Asynchronous events. Synchronous Events occur when the list is being updated and have two types of properties: Before Properties and After Properties.  Before Properties contain the value of the List Item before the list is being modified and After Properties contain the value once the list is updated.

To access these properties we need to use the SharePoint Internal Column Names and the Column names displayed in UI (Display Names).

As such, during programming, SharePoint uses the Display Name for some scenarios and Internal name for others. For example, when you are working with asynchronous events you can use a display name like “My Column Name” to retrieve the value. However, when you work with synchronous events and when you need to access After Properties you should use the Internal Name, such as “My_x0020_Column _x0020_Name”.

Event Receivers work well when the List Items are updated through the SharePoint User interface, but when the items are updated programmatically (e.g., through a custom web part) event receivers might not be triggered. This is because the application/web part gets terminated faster than the output can be received from SharePoint and SharePoint doesn’t recognize that the event actually occurred. So when the list items for an event receiver is updated programmatically, it is better to use System.Threading.Thread.Sleep(1000); immediately after item is added or updated just to make sure SharePoint recognizes the event.

January 3, 2014


Email [email protected] with any questions you have pertaining to this course.

New CPE Accredited Courses Now Available for Dynamics AX, GP, and NAVEARN CREDITS TODAY