It should come as no surprise that Microsoft’s strategy for SharePoint 2013 is cloud-based, SaaS, Hosted Services or whatever you want to call it. Whatever the name, the outcome is that custom, server-side code is no longer the way to go in the SharePoint world. This brings into question the fate of one of the workhorses of SharePoint since 2003: the Event Receiver. Microsoft has done a great job of exposing web services and creating the Client Side Object Model to enable scripting, but that doesn’t work when your application needs to react to an event that occurs in SharePoint.
SharePoint workflow could provide some of that functionality, but there is an overhead cost to workflow. When architecting a SharePoint-based solution and the question “Workflow or Event Receiver?” comes up, I always prefer event receivers until it’s proven that the process needs a workflow. If all the process needs to do is fire off an e-mail or update a field in another list or database, then why incur the overhead of a workflow when an event receiver will do the job with minimal management and overhead? But that doesn’t work in an app for SharePoint or in a hosted environment that doesn’t allow custom code…or does it?
I’m guessing you can tell from the title of this post what the answer to that is — yes, with remote event receivers.