Here's some shared wisdom from our experience with SharePoint consulting. SharePoint workflows are an exciting method of providing business process automation however they are notoriously temperamental.
The Deep Problem
SharePoint workflows use timer jobs and run under the security content of the initiator for any recurrent process. Timer jobs are full trust solutions and when written badly can seriously impact your farm, not to mention if you did write one for every recurrent process you ever needed, you'd end up with an unmanageable number of processes and code. Looking to the future, if you ever considered moving to The Cloud e.g. Office 365, such Full Trust solutions would not be allowed, and your business would find itself scrambling at great cost to replace the functionality in another way. Actually, Timer Jobs are so Cloud Unfriendly that they were forgotten in O365.
So Microsoft created the SharePoint 2013 Workflow platform which uses the new Workflow Manager Service. Workflow Manager is built on top of Windows Workflow Foundation. They also made Visio 2013, an Office application that is used to build diagrams by using shapes and connectors. You can use Visio 2013 to build workflows based on the SharePoint 2013 Workflow platform. You can import workflows from Visio 2013 into SharePoint Designer 2013, and vice versa. It's a bit complex.
What we actually use
It's not a secret that event handlers are far more reliable than workflows. Event receivers can be attached to a list and run code in response to events raised. Many actions, alerts and other features function as event receivers, and additional workflows and other 3rd party components might be attached to the list as well. A SharePoint event handler or event receiver is a piece of code that runs when an event, such as the adding, deleting, or changing of a SharePoint list item or document, takes place.
SharePoint event handlers vs. SharePoint workflows
The main differences between SharePoint event handlers and SharePoint workflows are SharePoint event handlers are automatically initiated, while SharePoint workflows can be initiated either automatically or manually. A SharePoint event handler always responds to an event that has taken or is taking place on an item, while a SharePoint workflow does not necessarily have to react to an event that is taking place. While it can react to an item being created or changed, you can also manually start a workflow after an item has been created.
The Game Changer
Event Receivers used to be created using Visual studio – with Workflows created via SharePoint user interface. Then Vlad wrote the basis of Infowise Smart action pro in under a week. That was years ago and the rest is history. We now use Infowise development tools for all our apps as they are fast and efficient. They ensure rapid and agile prototyping and development so we can involve our clients early in the development process. The earlier they can see it the better the end result aligns with their needs.
Yes they are deeply integrated in SharePoint
How do they work? They generate XML files for each list and their solutions read these XML. Sounds simple right? Consider you could build a form that created a new user in AD, populated their information, and placed them in the right OU group, and had an approval process along the way, and sent them an email when done!
And yes we are their partner!
We love helping with SharePoint and it's all we do so feel free to contact us!
Mention this post and we'll send you a white paper all about why Infowise is right for you! As SharePoint consultants we strive to empower our clients to unlock the full potential of their SharePoint environment.