Remote Event Receivers in SharePoint online

Remote Event Receiver in SharePoint online

In SharePoint Online, to handle list and list item events by creating Remote Event Receivers (RERs), which are web services that run externally to the SharePoint Online. The URL of the RER service is registered for the events it handles.

Working of Remote Event Receivers in SharePoint online:

  • The user performs an action on SharePoint (for example, upload a document to document library).
  • SharePoint then talks to the registered web service.
  • The web service can also talk to the Access Control Service (ACS) to request its own signed token to do a call back to SharePoint. Using this token, you can perform remote actions from within the web service as a result of the earlier operation on the list item or in the backend system.

Remote Event Receiver hosting recommendations:

  • The remote event receiver can be hosted in the cloud or in an on-premise server that is not also being used as a SharePoint server.
  • The URL of a production receiver cannot specify a particular port. This means that you must use either port 443 for HTTPS, which we recommend, or port 80 for HTTP.
  • If you are using HTTPS and the receiver service is hosted on-premise, but the add-in is on Microsoft SharePoint Online, then the hosting server must have a publicly trusted certificate from a certificate authority. (A self-signed certificate works only if the add-in is in an on-premise SharePoint farm.)
Permutation Consideration
Office 365 + app in Azure Websites Recommended. 

·  This is compelling because it’s free, quick and easy to spin up, and you don’t need to provide any in-house servers (with the resulting high availability, scalability, backup/restore and performance work which is required).

·  Another significant factor is that you don’t need to involve your gateway/networks team in getting the website (which hosts your provider-hosted app pages and/or WCF service for your Remote Event Receivers) published (on SSL of course) and accessible externally – e.g. through UAG, or whatever your perimeter device may be.

·  Azure is already outside of your firewall and accessible/addressable over the internet of course, and Azure Websites have automatic SSL support on the default domain (which is *

·  If you want to use a custom DNS host name instead (e.g. then you can do that too, with some extra steps.

In general, using Azure Websites is a great way to sidestep many of the infrastructure roadblocks which can derail you.

Office 365 + app in on-premises server More complex due to operational I.T. challenges.

Creating and Debugging Event Receivers (using Azure service bus)

We can debug the Remote Event Receivers using Microsoft Azure Service Bus. In this case we don’t need Azure / on-premises server to host the services, we can host the service in Azure Service Bus.

You can get a very good example from the following link:

Remember, we need to handle the code for attaching the event to the list when install the receiver. Unfortunately, it is impossible to remove the event receiver that are added through service bus. The only way  is to delete the list. Receivers, written by published service (in Azure) can be removed properly.

Publishing the Remote Event Receivers (Host service in Azure)

You can get a very good example from the following link:

Remember to handles the app installed/uninstalling event with this. After the app gets installed, it attaches the Remote Event Receiver with the list and during the uninstalling event, it deletes the Remote Event Receiver from the list.