Performance and Development Workflow Updates in SharePoint 2013

SharePoint 2013 introduced exciting workflow updates that increase the reliability and scalability of workflows.

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 later.

Two major features in 2013 workflows was adding loops to the workflow actions in SharePoint designer, and supporting workflow designer 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 improved the process of debugging a workflow. Stages, log list, Debugging in VS (activity breakpoints), workflow manager logs are all options that can now be used.

Performance Updates

Now let’s look at the improved performance in SharePoint 2013 workflows. As we all know, SharePoint 2013 workflows run on a different box and reduces load on the 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 backend). 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 backend component will notify SharePoint that the workflow process has started, and 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 backend 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 that it was started for the first time.

The role of the service bus makes the workflow more reliable and scalable.

Upgrade to The New Workflows

The new SharePoint 2013 workflows provide enhancements to development and performance that can extend your current SharePoint solution. Are you currently on 2010 and looking to upgrade, or want more information on the workflow updates? Our team at FMT can help support your existing solution and map out an upgrade path that makes sense for your organization. For more information, contact us by filling out the form below.

Written by:
Yahiya Iqbal
Senior Consultant