Workflow, from a work management perspective, is the steps taken to move a process from a particular starting point to a particular endpoint. Often, workflow is confused with business process automation. However, it is more accurate to identify workflow as a part of business process automation - a piece of the whole solution. In fact, business process automation - the activity of completing work tasks automatically - is often comprised of several distinct workflows.
Why all of this complexity?
Because workflow is complicated. However, it is very important to understand what workflow is in order to leverage it properly. The reason workflow is defined as moving a process from a particular start point to a particular endpoint is to show that not all workflow runs end to end. Much workflow runs for only a portion of an entire process. An invoice process does not end at the manager's approval, but there may be a workflow to automate that particular portion of the invoice's work process. After approval, a different workflow may be triggered, or several workflows in parallel. All of these workflows when strung together define the automation of the entire business process - your work.
Understanding workflow is also important because technology may help automate the steps of a workflow, but this "workflow technology" is a tool. It is not the active workflow itself. It is a set of instructions on what to do logically (in the case of SharePoint - programmatically) to move the process along. The process, or activity, needs to be mapped into the tool in order for the tool to do anything.
This guide will look at the workflow tools provided out-of-the-box in SharePoint, and what needs to be considered in order to get the most out of these workflow tools.
Workflow in SharePoint
Workflow in SharePoint out-of-the-box is task driven and linear. It is designed to move a process along in a simple series of steps by assigning tasks to users and then moving to the next step in the process based on the users response to the task. The task can be an approval (yes or no), feedback, or a signature. Nonetheless, all out-of-the-box workflows in SharePoint assign a task to a user and the user then goes into SharePoint and responds to the task. It follows a simple line of thought (i.e., Is this approved? If yes, do something. If no, do something else.). This type of simplex linear workflow is often called ad hoc workflow. It is ad hoc (done for a particular purpose) because the workflow focuses on one task at a time.
The reason SharePoint workflow operates this way is to help reduce the complexity of workflow automation. Workflow automation in its truest sense is a complex arrangement of rules, routes, and roles. Rules define how to define the work and what route to send the work through. Routes are the 'paths' that the work can take. And roles are the participants levels of access to the specific work being automated. For example, for an incoming $500.00 invoice: the rule may be "get the value of the total amount due on this invoice", the route may be "send it to accounts payable for payment" (this assumes that an invoice for $500.00 needs no other approval in order to get paid). The roles are a 'submitter' - in this case the company that issued the invoice, and a 'payor' - a person from accounts payable that can issue payment. Different routes can have different roles (i.e., if the invoice is greater than $500.00, it may require a manager to sign off on the invoice, and/or the CFO to approve the payment before it can be paid: these would be 'approver' roles).
Further, these rules, routes, and roles may be dynamic and change based on variable conditions. For example, does the invoice go to one particular payor in accounts payable, or does it go into a pool of payable invoices for different members of accounts payable to process in turn? What would happen if one of those payors were to be out of office? Do they still have invoices assigned to them?
Planning a workflow out is challenging enough. Understanding and mapping these dynamic behaviors into a tool to automate these processes becomes overwhelming. The out-of-the-box SharePoint solution is to mitigate this complexity by limiting the capabilities of SharePoint workflow to more simpler tasks with binary (yes/no) outcomes.
This is not meant to mean SharePoint cannot handle complex workflows, or that it is not possible to build complex workflows into the SharePoint environment. It does mean, however, that the tools provided out-of-the-box to build workflows in SharePoint are built to handle simpler work. If the workflow grows too complex, a more robust workflow tool may need to be used to complete the task.
Starting with SharePoint 2013 (on-premise), SharePoint ships with two different types of workflow: SharePoint 2010 workflow, and SharePoint 2013 workflow.
SharePoint 2010 Workflow
As its name suggests, SharePoint 2010 workflow originated in SharePoint 2010, and was carried forward into SharePoint 2013. This was done to ease migration from SharePoint 2010 and 2013 by making sure that workflows built in the former version of SharePoint will still work in the latter version. This version of workflow is built upon older Microsoft frameworks (.NET 2.5.1) and was built specifically for SharePoint.
This means that SharePoint 2010 workflow was made to work specifically with content types, lists, libraries, and SharePoint sites. It "understands" SharePoint and helps make implementing workflows in SharePoint easier (do not confuse this with easy). The biggest drawback to SharePoint 2010 workflow, is that it does not work well outside of the SharePoint context. It has trouble when an organization wants to add work from outside sources into the workflow (e.g., a payment status from accounting software). It expects to perform all of its workflow solely inside of SharePoint.
One final note on SharePoint 2010 workflow is that it is seven years old (as of 2017). That's old by software standards. Its only a matter of time before SharePoint retires this workflow and phases out support for it in future versions of SharePoint (you are safe up to SharePoint 2016 for now).
SharePoint 2013 Workflow
SharePoint 2013 workflow is a more modern version of workflow that was released in SharePoint 2013. It uses more modern Microsoft frameworks (.NET 4.5+) and it provides for powerful features including a better ability to work with information coming in from sources outside of SharePoint. It is different enough to SharePoint 2010 workflow that they are incompatible with each other, thus the two different types of workflow.
The major reason for this incompatibility is that SharePoint 2013 workflow did not originate in SharePoint. It came from Azure and uses Azure's workflow manager and workflow client architecture. This is very powerful, but was not built with SharePoint in mind. This does not mean it works poorly in SharePoint. In fact, it adds some very important features to workflow that make it more powerful in SharePoint. It does, however, make things a little more complicated.
Workflow in SharePoint 2016 and SharePoint Online
Workflow was not significantly updated in the latest release of SharePoint 2016 (on-premise) and SharePoint online. SharePoint 2016 still uses SharePoint 2010 and SharePoint 2013 workflow. However, this latest release is also going through a significant set of changes to the typical SharePoint build and release cycle (usually every three years). Originally, SharePoint was built as an on-premise platform first, and then SharePoint online would inherit the on-premise features over time. Going forward, this is being flipped. This change is going to impact how workflow is going to be supported, and thus how your organization will need to plan out workflow in SharePoint. There will be more discussion on this aspect later in this article.
Out-of-the-Box Tools for Workflow in SharePoint
Workflows in SharePoint are built by using templates. Templates are the instructions of the workflow. They are built outside of SharePoint in a tool called SharePoint Designer (SPD).
SharePoint Designer is a special application that is downloaded and installed on a user's computer. SPD then connects to the SharePoint site and the user can perform many different operations on the SharePoint site. One of these operations is workflow.
The SharePoint Designer workflow designer tool allows a user to create several types of workflows based on how the workflow is intended to be used. The three types of workflows are Site Workflows, List Workflows, and Reusable Workflows. As their names suggest, a site workflow attaches to the SharePoint site and typically uses information gathered from forms, and performs actions at the site level, while a list workflow attaches to a list or library and performs its processes there. A reusable workflow can be used on content types directly* (when you use a SharePoint 2010 workflow), or on lists and libraries. Further, reusable workflows can use InfoPath forms to gather all pertinent information to create and route tasks and not rely on any information coming from any source (e.g., a list, library, or content type) and can therefore be used anywhere. When this is the case, they are called globally reusable workflows.
Once the type of workflow is selected, the user can define the 'flow' (the template) of the workflow. This is done by using conditions and actions in a series of steps (in SharePoint 2010 workflow), and additionally stages and loops (in SharePoint 2013 workflow). Conditions are clauses of if/then conditions (e.g., if the invoice amount is less than or equal too $500.00), and the actions are the behaviors that you can perform. The types of actions you can perform depend on the version of workflow selected (SharePoint 2010, or 2013 workflow). Typically, SharePoint 2010 actions are more intuitive, but focus on internal SharePoint behaviors (i.e., start an approval task, etc.) while SharePoint 2013 actions tend to be much more developer focused (less user friendly), but offer more power and capability.
Stages and loops are exclusive to SharePoint 2013 workflows. Stages make it possible to create more versatile workflows by being able to go to a different stage based on output from the workflow (i.e., if the invoice amount is greater than $500.00, and it was approved by a manager, go to the CFO approval stage). The only way this could be replicated in a SharePoint 2010 workflow would be through a complex set of if/then conditions. Loops allow SharePoint 2013 workflows to cycle through a set of actions until a condition is met (i.e., remind the manager of the pending task via email daily until the manager either approves or rejects the task.).
Once the template of the workflow has been built in SharePoint designer, it can be published to SharePoint, and then applied. Once the template is applied in SharePoint, it can be tested to determine if it works as expected. The workflow template can be checked for errors in SharePoint designer prior to being published to a SharePoint site, but this form of error checking is specifically for syntax errors. It does not verify if the workflow will work as expected in the site itself. Changes to the template require re-working in SharePoint designer and re-publishing back to the SharePoint site.
There will be times when SharePoint Designer will not be enough. The actions are not capable of performing the tasks you need to do. The answer at that point is to use Visual Studio. This is the developer's tool, and is not ever meant to be used by end users. However, it can be used by developers to build very sophisticated workflows - provided the developers clearly understand what it is they are trying to automate for you.
If this sounds very complicated, and more developer oriented that's because it is. This raises a typical situation in SharePoint workflow development. Users are the closest to the work that they wish to have automated. They work with the process everyday. However, the tools provided by SharePoint to help design workflows are not user friendly, and are typically developer focused. Developers are insulated from the user process. This requires that a strong team comprised of both users and developers must be created in order to clearly define the process that is going to be automated.
Now, The Hard Part
You have two choices of workflow out-of-the-box in SharePoint. The question is which one to use?
You may have noticed an asterisk(*) and a parenthetical disclaimer in the previous section. It is there to inform you that attaching workflows directly to content types is not supported for SharePoint 2013 workflows. This is a BIG change with a very big impact.
The core of the SharePoint content model is the content type. It is the basis to identify discrete work in your SharePoint environment. It makes sense then that one would be able to apply workflows directly to content types when necessary. Well, you can - but you need to use SharePoint 2010 workflows to do it. And, SharePoint 2010 workflows are older, and not as powerful or flexible. Moreover, what about future versions of SharePoint? The reason SharePoint 2010 workflows still exist in SharePoint 2013 (and 2016) is to maintain support for them as SharePoint gets upgraded. This support is going to end at some point.
Further, the tools used to make workflows work in SharePoint are impacted. The default forms tools for SharePoint 2013 was InfoPath. InfoPath has been sunset by Microsoft. Likewise, SharePoint Designer did not get an update to a 2016 version. All the tools are being phased out. So what now?
First of all, expect what is presently in place to be supported for a while longer. SharePoint Designer 2013 will work with SharePoint 2016 and SharePoint Online for some time still, as will the workflow components. However, expect a big change in how forms and workflow will be handled in the future. Its coming from the cloud in the forms of Power Apps, and Flow: both new apps coming down from the Microsoft Office 365 space.
Workflow is going to be a big area of change in SharePoint's future. It is no longer going to be SharePoint centric, and only look within the confines of your SharePoint environment. This is good. Your work is also not confined to SharePoint. However, that means that what you have in your SharePoint now may need to be changed in the future in order to keep up. This change is going to be hard considering SharePoint workflow 2010 and SharePoint workflow 2013 are not even compatible with each other. Expect a rocky transition.
But don't fret. The cloud tools are much more user friendly, intuitive, and connected. This means your work management will be also. As these tools mature and grow in capability, it will be easier to transition to them. Just be aware that this transition will be manual - new workflows will have to be written eventually.
Finally, workflow is always evolving. The first (successful) workflow you write will need to be updated as your work management needs change. It will actually make sense to write completely new workflows and retire the old ones over time. Now, you have something to look forward to.