Many developers are now very much used to developing solutions using SharePoint 2013 but, as SharePoint is such an expansive platform, it is not surprising that many people have not yet used all of the fantastic features that the latest incarnation of the platform made available when it was released.  One such area is that of SharePoint workflow.

Workflow only saw an evolutionary change between SharePoint 2007 and 2010, but with 2013 all that has changed with a complete overhaul to workflow and this article seeks to inform you about this revolutionary change.

Backwards Compatibility

Firstly, let’s get one thing out of the way, which will be on many readers minds when reading this article – what about my existing workflows?  Do I need to rewrite my solutions to work with this new platform?  Thankfully the answer here is simple, no.  Up until SharePoint 2010 workflow was based on Windows Workflow Foundation 3.5 and it will please many people to know that Microsoft have made SharePoint 2013 backwards compatible for solutions built in the traditional style.  This is a nice touch in a world when so many times upgrading to a new platform means much additional re-work to existing solutions (as has often been the case for custom SharePoint solutions over the years).

Enter Workflow 2013

So, given that we are now comfortable in the knowledge that our existing work is not in jeopardy, what about creating new workflow solutions in 2013? 

Following the trend of Microsoft bringing the power of its Azure platform to its other estates, workflow is no exception, with the new workflow engine, known as Workflow Manager, being based on Windows Azure Workflow (WAW).  The first thing to point out about this new engine is that it is now based on Workflow Foundation 4.5, which brings with it many additional features and has been designed from the ground up to allow the creation of enterprise class workflow solutions. Secondly, Workflow Manager runs separately from SharePoint with your workflow solutions therefore also being able to be hosted externally.  This might either be in Azure itself, or by installing Workflow Manager on-premises, as is now possible with many Microsoft Azure services. This ability to host your workflows externally has a few of significant benefits for SharePoint developers;

• Workflow load is no longer handled by SharePoint itself.  Let’s face it, SharePoint has enough to manage with its various other loads and so it is good to know that the task of executing workflow solutions can be offloaded.  When used on-premises, Workflow Manager is a separate install from SharePoint, which can either sit alongside SharePoint on the same server or within an environment all of its own.
   
• Workflow solutions built on Windows Azure Workflow are cross-platform out of the box, meaning that you can build workflow solutions that integrate with multiple systems.  Take the example of a workflow designed to track the receipt and processing of orders throughout their life-cycle.  Sure, we can built a robust system to allow us to use SharePoint to progress an order through to fulfilment, but with WAW, we can now also create a .NET client application that can also interact with the workflow, perhaps allowing field engineers to change the status of an order.  This also means that we can host all of our workflows, regardless of which platform they are working with, in a single place – and everyone likes to be tidy right?
   
• The ability to create and host Workflow solutions externally means that upgrade scenarios to future iterations of SharePoint should be more straight-forward than many of us have experienced in the past with custom solutions built on SharePoint itself.

Workflow Development

Unsurprisingly, such a change in the underlying workflow platform also has some significant impacts on the process to create and develop solutions for it.  Workflows are now fully declarative, meaning that their definition and execution paths are actually described in a series of XAML files.  One thing to call out right now with this new declarative based approach is that the traditional code approach to workflow development is gone – that’s right, you read that correctly!  Don’t worry too much though, that doesn’t mean that we cannot create custom logic when developing our workflows, but now you encapsulate this logic within web services and interact with them using activities.  Activities are objects that handle calls to APIs that drive workflow execution and behavior, including calls to web services (more on activities later).

In terms of tooling for this new declarative approach, SharePoint Designer 2013 was overhauled in terms of workflow to be, in Microsoft’s words, “the authoring environment of choice for authoring SharePoint workflows”.  Among some of the changes to workflow authoring that can be found within SharePoint Designer is the introduction of Loops, something that has been lacking within workflows until now.  These loops are much like the loops seen for years, allowing for looping through a process a set number of times or looping until a specific condition is met. 

SharePoint Designer is undoubtedly a good tool for authoring workflows, but I can feel the shudders of many SharePoint developers out there who don’t want to work with the tool and instead prefer the comfort of their Visual Studio IDE.  Fortunately, Microsoft have also brought these authoring capabilities to Visual Studio in the form of Workflow project templates, namely Sequential Workflow and State Machine Workflow, and this allows workflows to be created using the designer and the properties window within the IDE.

Actions and Activities

As I already mentioned, activities are objects that handle calls to APIs that drive workflow behavior, whereas actions are objects that encapsulate these activities and allow us to include them in our workflows and can be included as part of your workflow using the design tooling mentioned above.

Whether you are using SharePoint Designer or Visual Studio to create your workflow, Microsoft have gone a long way to anticipate the types of actions you might require when building business workflows.  The list of available actions within Workflow in 2013 will likely satisfy even some of the most demanding requirements, with many new actions introduced, including those with the ability to start a list or site workflow, several designed to interact with Microsoft Project and the ability to call a HTTP Web Service. There are too many to go into any sort of detail in this article, but you can find a handy reference to them all at http://msdn.microsoft.com/en-us/library/office/jj163867(v=office.15).aspx, which provides you with a list of the available actions and activity classes.

But what if they aren’t enough and you find yourself requiring something a little more custom?  Well, Workflow 2013 also brings support for Custom Actions. Recognising that business requirements are often complex and specialized, Custom Actions can be created using a Visual Studio template and once created can be packaged and deployed to SharePoint, at which point they become available to you and other workflow authors in tools such as SharePoint Designer as if they were part of the out of the box library of available actions.  A good overview of Custom Actions and an example of how to build your own can be found on MSDN at http://msdn.microsoft.com/en-us/library/office/jj163911(v=office.15).aspx.

Summary

The changes seen in workflow within SharePoint 2013 are significant and whilst some of them mark a paradigm shift in terms of their development, such as their declarative xaml based nature, there are many benefits to the new approach.  For me the simple fact that workflow has now effectively been de-couple from SharePoint allowing for cross-platform workflow development makes the new world of workflow an exciting one.