This SharePoint tutorial explains, the difference between event receiver and workflow in sharepoint 2013/2016 or SharePoint Online.
Both workflows and event receivers are very important in SharePoint and it is important to know which one to use when.
Let us discuss workflows and event receivers in SharePoint 2013.
Before discussing the differences, just to let you know that both workflows and event receivers perform mostly the same functionality in SharePoint.
SharePoint Online tutorial contents:
SharePoint workflows allow us to automate business processes. The business processes can be from simple (document approval) to
Event receivers in SharePoint allows certain code to execute when a event triggers on a specific SharePoint Objects. The events can be itemadding, itemupdating, itemdeleting, checking in, checking out etc.
There are different ways we can develop workflows in SharePoint.
- Out of box using a browser
- SharePoint designer 2013
- Visual Studio 2017/2015
- 3rd Party Tools like Nintex
But we can develop event receiver by using visual studio in SharePoint 2013/2016/2019.
But we can not use event receivers in SharePoint Online, we can use event receivers in SharePoint on-premises only. We have to use remote event receivers for SharePoint Online.
Event receivers in SharePoint can be executed before or after an operation, like before adding an item or after adding an item. On the other hand workflows can be executed only after the operation happed like after an item added to the list or after an item update.
The event receivers in SharePoint 2013 or event receivers in SharePoint 2016 cannot be launched manually. They always attached to a SharePoint object which will run automatically when the event occurs. But workflows can be started automatically as well as can be started manually also.
By using an event receiver you can there is a chance that you can cancel the operation but in workflows you can not cancel the operation because already the item has been created.
A SharePoint workflow can be started like manually, when item is added, an item updated etc but an event receiver can be in action in various events which includes delete item also.
You will not have any UI interaction in case of event receivers in SharePoint, but you can use various forms like initiation forms, association forms in a workflow for user interaction in SharePoint. Also, SharePoint workflow provides a Workflow History to log information by default, but there is no such feature in the case of event receivers.
Event receivers will not survive after server reboots, where are SharePoint designer workflows does survive. Event receivers are running in a particular Web front-end server, so if something goes wrong in the WFE, it may end but workflows will not.
Event receivers can be run for a very short period of time whereas SharePoint workflows can run even for days, week, months or even for years.
If you got this kind of requirement, then first check if the requirement is to cancel the process then you should use event receiver. On the other hand if your business requirement wants user inputs then you should choose for workflow.
Both event receivers and timer jobs do almost similar tasks. But timer job executes tasks that run at a scheduled time.
You can run a timer job one at a time or on a recurring schedule.
Timer jobs perform mostly the back-end work for the SharePoint. SharePoint timer jobs run in the background, with no dependency on any user interaction. Even if no users are accessing the SharePoint site, timer jobs will run on the particular schedule.
Like event receivers you will have to use Visual Studio for developing timer jobs in SharePoint.
Which is better workflows or event receivers in terms of performance?
This is tricky, because it depends on the requirement.
Both workflows and event receivers are really different. Without developer knowledge, you cannot write an event receiver. But business users or site administrators can develop workflows using SharePoint designer 2013.
Below are the scenarios where you should consider workflows.
- Does any user interaction occur?
- Will the process run for a long time (more than a second or two)?
- Will the process need to pause to wait for another process to complete a task?
- Will the process be run many times (more than 25 or 30) concurrently?
If the above answers are Yes, go for a workflow, else go for an event receiver.
If you are running a large number of event receivers then it has performance implications. If the process takes longer than five minutes to resolve, that is another case where a workflow is more appropriate than an event receiver.
You can check the below tutorials:
I hope you got an idea of the difference between workflows and event receivers in SharePoint.
Hello Everyone!! I am Bhawana a SharePoint MVP and having about 10+ years of SharePoint experience as well as in .Net technologies. I have worked in all the versions of SharePoint from wss to Office 365. I have good exposure in Customization and Migration using Nintex, Metalogix tools. Now exploring more in SharePoint 2016 🙂 Hope here I can contribute and share my knowledge to the fullest. As I believe “There is no wealth like knowledge and no poverty like ignorance”