In the latest release of SharePoint 2013, Microsoft made some dramatic changes to the workflow engine, how it interacts with SharePoint and how customers can create custom workflows. Prior to SharePoint 2013, Microsoft implemented workflow by having SharePoint host the Workflow Foundation runtime. This meant that workflow scaled as SharePoint scaled and anything customers wanted to do with workflows, such as start new instances on a list item or interrogate the runtime for currently running workflows, or even to get telemetry data on previously run workflows, all had to be done through the SharePoint. While this was fine in many scenarios, it was also very challenging and limiting because the SharePoint API did not expose all the details of the workflow runtime. To implement this architecture, all workflows executed under a highly-privileged account that, while acceptable for on-premises SharePoint deployments, caused significant issues in hosted deployments such as the popular Office 365 service offered by Microsoft. As such, customers could only deploy workflows created using SharePoint Designer as they were fully declarative and thus had no custom code that required the highly privileged account to execute them.

SharePoint 2013 introduced a dramatic change to this architecture. The Windows Azure and workflow teams worked together to create a new product,Workflow Manager 1.0, which acts as the host for the workflow runtime. This product can run both in Windows Azure as well as in on-premises deployments. How does this impact SharePoint 2013? In the latest release, Workflow Manager is configured as an app with SharePoint and SharePoint relays all workflow processing and work to it. This separates the workflow workload from SharePoint 2013 that will provide more options for extensibility, scalability and because Workflow Manager was designed for the cloud and on-premises deployments from the start, everything you can do in an on-premises deployment can also be done in the cloud and vice versa.

Outsourcing workflow to Workflow Manager mandates some changes

It should not be surprising that such a dramatic architectural change will mandate some changes to workflows SharePoint developers are accustomed to building. Of all the impacts this shift has on custom workflows, they can be grouped into two categories: a new client-API and web services. Both of these categories have plenty of things they impact so let me touch on a few of them.

One giant step for workflow: A new client API is needed

One significant improvement to the workflow story in SharePoint 2013 is the added coverage of the workflow services infrastructure in the client side object model. This implementation, available form server-side code (commonly referred to as CSOM) or from the client as JavaScript (commonly referred to as JSOM) enables developers to do virtually anything with workflow in SharePoint 2013. Developers can create custom solutions that validate and install new workflows, create new and modify existing workflow associations on lists, libraries and sites as well as start new workflow instances and even interact with those that are in-flight and currently running!

These changes were needed for multiple reasons with the new architecture, but one stands out from the others as it dramatically simplified a common task for workflow developers: creating custom forms. In previous versions of SharePoint, creating custom workflow association and initiation forms was a cumbersome task using either ASP.NET with special and complex custom server-side code used to marshal the communication from the form to the workflow engine or using InfoPath forms which were hard to deploy and debug.

This is not so in SharePoint 2013. The inclusion of workflow in the CSOM & JSOM means that now, all forms are essential just HTML forms that use JavaScript to create the association or fire off a new instance of the workflow. In fact the templates included in Visual Studio when you add a new form stub out 98% of the JavaScript needed to add these forms; all you have to do is fill in a few blanks for your custom fields!

Extending our reach beyond SharePoint and Workflow Manager: Web services

Workflow Manager 1.0 also introduced a new capability to SharePoint workflow developers that was previously only available to those building coded workflows using Visual Studio: the ability to interact with external web services.

The ability to call external web services, ideally OData or REST services, is very important in this release as another big change to the platform. The new SharePoint 2013 + Workflow Manager 1.0 style workflows only support declarative workflows; developers no longer create workflows in Visual Studio with a code-behind model… even Visual Studio authored workflows are now 100% declarative.

When you have custom business logic you need to implement in your workflow, Microsoft recommends you refactor this logic into an OData service and call that service from your workflow.

These services can anonymous services or they can be configured for authenticated only scenarios with various options employed to secure the services from unauthorized calls.

In addition to calling your own custom services, another powerful use case for leveraging web services in custom workflows is calling the SharePoint 2013 REST API when some of the actions or activities provided in SharePoint Designer or Visual Studio don’t suit the needs of your business requirements. In those cases you can take full advantage of the powerful SharePoint REST API to achieve anything you need to do in your workflow!

Microsoft made some significant changes to the workflow implementation in the latest release of SharePoint, SharePoint 2013. These changes make it easier for developers and power users alike to create custom and robust workflows that automate business process. In addition, the new architecture also makes workflow a much more transparent, reliable and scalable platform for SharePoint customers regardless if they have on-premises deployments or leverage hosted solutions such as Office 365.