SharePoint 2013 has a myriad of new features, bells and whistles. One of those neat features is the new and improved SharePoint 2013 Workflow. SharePoint 2013 Workflow allows for many new capabilities, but at the same time removes some key items from 2010 workflows. So what’s the right workflow to use? The consultant in me must reply, “That depends on the situation.”
Key capabilities only provided by SP2010 workflows
One would think that a new version simply takes the existing pieces and makes them stronger or adds to them. Not in the case of workflows. SP2010 workflows have some key features that are missing in 2013 workflows.
If and else if: One of the items removed in the transition to 2013 workflows is fairly simple, but actually makes things much more complex than they need to be. In 2010 workflows, we can create If, Else If, Else conditions. 2013 workflows only allow for If and Else. This requires very messy and visually appalling nested ifs.
#!Impersonation Steps: While nested ifs are just an inconvenience, the inability to replace item level permissions is an actual hindrance. SP2010 workflows allow the workflow to replace the permissions of an item after it has been created or modified. When does this come into play? If you can imagine a scenario where an item is created, and then we need to set permissions so that only certain users can edit it, we can use the item level permission replacement. Many times this is done through InfoPath via security by obscurity (switching to a read-only view of the form based on user role). Replacing item level permissions is a full solution for this and is only possible in SP2010 workflows using an Impersonation Step.
User Information: Only SP2010 workflows allow some user information actions. Using the User Profile as a lookup is only possible in SP2010 workflows. We also only get the Lookup Manager of a User in SP2010 workflows. When not using InfoPath (or whatever forms solution will come in the future), these actions allow users to get important information for potential email and approval processes without requiring entry from the user.
Document Sets: Document Set actions do not exist in SP2013 workflows. This is an interesting omission. It would seem to mean the potential demise in the future for document sets. If you have document sets that you need to interact with, SP2010 workflows may be your only option.
#!Key capabilities only provided by SP2013 workflows
Out with the old, in with the new! SP2013 workflows, while incapable of if/else statements and impersonation steps, still have some great new tools that SP2010 workflows don’t provide.
Stages, loops and calling other workflows: Unlike the differences in if/else conditions between 2010 and 2013, stages actually provide a significant amount of functionality rather than just being a nuisance. If you’re used to programming, stages can be viewed as functions. Normal programming functions would allow us to call other functions and skip around. SP2013 workflows can’t freely call other stages, but they can call SP2010 workflows at will and use the transition stage to skip around and go back. If you can imagine a scenario where you just want a workflow to continually repeat, SP2013 workflows allow you to keep repeating the same stage. Additionally, if you need to potentially skip steps based on conditions, we can accomplish this in the transition stage as well.
Similarly, loops allow us to keep repeating actions a certain number of times or until a condition is met. This is exactly the same as a for or do until loop in programming. This is very important if we want to do things like creating tasks for multiple users or breaking large chunks of information into smaller, consumable parts.
#!HTTP Web services and dictionaries: One of the biggest enhancements of SP2013 workflows is the HTTP Web Services functionality. Remember all those things that I said you can’t do in a 2013 workflow? Well you probably can, actually; you just need to create a web service to do it.
The most common use I have experienced so far for calling an HTTP Web service is when we need to pull in list information. By using the REST API, we can build a new 2013 object called a dictionary and populate it with list info. Dictionaries are like arrays. Once we populate it, we access the info via the index, most easily accomplished with loops.
There are a lot of possibilities with this new functionality, and it will be interesting to see what the SharePoint Community develops from it in the future.
So… Recommendations?
Now that we know the differences, what is the final deciding point? Obviously if you must use HTTP Web services, loops, stage jumping or dictionaries, then 2013 is your only option. If you need to work with list item permissions or document sets, then you will have to do a 2010 workflow (or create a Web service). You could then call the 2010 workflow inside of a 2013 workflow if it is part of a larger process.
But what about when you don’t fall into those obvious categories? This is where planning for the future comes into play. If you can’t predict whether or not you’ll need to extend the workflow into 2013 functionality in the future, it may be best to start with a 2013 workflow so that you can utilize those functions. If you ever need to use 2010 functionality in the future, you can call a 2010 workflow or create a Web service, but you can’t get 2013 functionality in 2010 workflows. If you are 100% positive that your workflow is a simple one and will remain that way, then 2010 workflows are likely the route you should take. The nested ifs of 2013 workflows just make them harder to read, and else/ifs are used in a vast majority of workflows by the common user.
The choice is yours. Planning ahead of time is always the best route!
Andy Wessendorf has been a SharePoint Consultant since 2010. During that time, he has excelled in taking business processes and turning them into effective and efficient information systems and utilizing out-of-the-box resources to create elegant solutions for complex problems.
