As Microsoft announced at end of July 2016 that coded sandbox solutions will stop working, any existing event receivers must be moved to one of:
- Remote event receiver in a provider hosted app
- Workflow
- JavaScript that runs on the New or Edit forms
Each has advantages and drawbacks, so you would plan ahead. Actually at the time of writing, transitioning from existing working coded sandboxed solutions is very rough because coded sandboxed solutions cannot be activated anymore, making testing in a site collection separate from production impossible.
This post only touches lightly the subject, so if you need help, please contact us and we’ll try to give a hand.
Remote event receiver in a provider hosted app
This would probably be the most robust option, but also the most complex and one that requires additional hosting costs. Also, the fact that that the service must pe SOAP would probably push back a lot of people.
Workflow
Workflows can be set to start automatically on a new item or when an item is changed, so this would make for a good substitute. Only thing is that we don’t have synchronous capabilities like an event receiver could have been, so we need to analyze if a workflow is suitable.
There are two main type of workflows when it comes to development tools: SharePoint Designer workflows and Visual Studio workflows. Apart from the tooling, there’s an important distinction between them which is very important in our scenario: performance. VS workflows are way faster and kick off without delay, whereas Sharepoint Designer ones tend to take their time, making for a laggy experience. So if you’re comfortable with VS, you’d definitely choose it.
JavaScript that runs on the New / Edit forms
Actually one might need to combine this option with the previous one to achieve what was so simple to do in an event receiver.
In order to to this, you would most probably set the JSLink of forms.
