SharePoint 2013 introduced exciting workflow updates that increase the reliability and scalability of workflows. These updates will become the standard moving forward into SharePoint 2016 and beyond, and open up the opportunity for further enhancements in the future.
Before we discuss SharePoint 2013 workflows, it’s important to first understand the 2010 workflows.
The 2010 workflows are not as reliable as the new 2013 workflows, due to their lack of scalability and availability. However, one of the major benefits of SharePoint 2010 workflows is that you can send emails across domains which wasn’t carried over in SharePoint 2013 through the send email action.
Microsoft improved SharePoint 2013 workflows in two ways: performance and development.
Development Updates
Let’s discuss development first, and then, we will look into the performance part.
Two of the major life changing features added in the 2013 workflows were adding loops to the workflow actions in SharePoint designer, and workflow designer support in Visual Studio. Leveraging visual diagrams makes it a lot easier to present and understand workflows. (Please note that visual designer needs Visio 2013 Professional).
In addition to these cool features, Microsoft also introduced stages, or logical divisions, to complex workflows. This is a good way to communicate the current stage of the workflow with the end user, because the workflow column now updates with the current stage of the workflow.
Additionally, SharePoint 2013 workflows also improve how to debug a workflow. Stages, log list, debugging in VS (activity breakpoints), connecting to service bus via Service Bus Explorer and Workflow Manager logs are all options that can be used.
![]()
Performance Updates
Now, let’s look at the improved performance in SharePoint 2013 workflows. As we know, in SharePoint 2013 workflows, workflow runs on a different box and reduces load on SharePoint Server.
To understand SharePoint 2013 workflows, you have to understand Workflow Manager 1.0 and the role of service bus. In SharePoint 2010 workflows, every task had to be done by SharePoint itself. With SharePoint 2013 workflows, SharePoint only has to notify the Workflow Manager (front-end) that the item is created or updated using the HTTP POST method. Workflow Manager, then, notifies SharePoint that the request is received and publishes that message from SharePoint to the Service bus.
Service bus will then check if there is a rule defined for the specific message which is received, and notify the subscriber (Workflow back-end). If the subscriber is offline or the service bus is unable to connect to the subscriber, it will keep the message for a period of time. This makes the process more reliable and resilient.
Then, the workflow back-end component will notify SharePoint that the workflow process is started, and workflow back-end continues the process according to the actions defined in the workflow via web service calls.
If during the process for some reason, the workflow needs user input, it registers the workflow to be notified for that specific task (what really happens in the back-end is that the workflow reserves an ID for new task item that the user is going to create and sends the ID to the workflow for configuration). When the user has given specific inputs, the workflow is triggered the same way it started for the first time.
The role of the service bus makes the workflow more reliable and scalable.