You have SharePoint (2013 or Online) deployed to your organization, and you’re ready to start automating all of those business processes you’ve defined across your business units.
Everyone’s told you: This should be a breeze!
Well, let’s hold on a minute and examine your options before you start deploying all of those cool workflows you have mapped out. While “easy” is certainly a relative term, workflow automation in SharePoint can have its challenges. The biggest challenge of all is understanding the different options you have when constructing those workflows.
Let’s examine them:
Native, out-of-the-box SharePoint Workflows
All your company really wants, from a workflow perspective, is to allow for simple approvals on documents, or list items that are added to SharePoint. Great! This is the part of workflow automation that SharePoint does easily.
SharePoint comes with a few out-of-the-box workflows that you can attach to any list or library:
- Approval – SharePoint 2010
- Collect Feedback – SharePoint 2010
- Collect Signatures – SharePoint 2010. (Wait, I’m not using SharePoint 2010, why do these workflows say “SharePoint 2010”? That’s a fun story, and we’ll cover that in the next section.)
These workflows are pretty basic, and they allow you to specify certain criteria to perform the types of Approval or Collection you want to accomplish. For instance, in the case of the Approval workflow, you can specify an approval chain of users who must approve the document/list item, as well as the duration of time they have to approve the item:
Easy right? Now you might be wondering “Ok, that’s great that I can get approvals done, but what if I want to update our custom status column after it gets approved? Or what if I want to create a new list item after it’s approved?” This is where we take our next step into more complex workflows. Time to jump into SharePoint Designer.
SharePoint Designer Workflows
SharePoint Designer allows you to create more complex workflows using a GUI-based design interface. It loads certain Conditions and Actions that allow you to map out your business process and put logic around it. For example:
This is a simple workflow, that says: “If Jo Karnes is in the name column on this list item, Log it.” SharePoint Designer Workflows can provide much greater flexibility when you need to do custom processes.
With the SharePoint 2013 release, Microsoft changed the architecture on how they handle workflows from the 2010 version of the platform. It created an entirely separate product to handle workflows (Workflow Manager), as opposed to their 2010 version, which handled all the workflows through SharePoint. This brought the added bonus of custom developed workflows to allow for greater complexity, but also abstracted the workflows from the core SharePoint engine, to help it fit into the App Model. This keeps developers from crashing the platform.
As I mentioned before, the out-of-the-box workflows show “SharePoint 2010.” That’s because the latest version of SharePoint still supports these legacy versions of workflows for backward compatibility. However, with the new SharePoint 2013 workflows, Microsoft also removed some of the Conditions and Actions that existed in 2010.
For example, in 2010 Workflows there was an action called “Copy List Item,” which was removed from the 2013 workflows. The good news is, you can still call 2010 workflows from a 2013 workflow. The bad news is, this just gets even more confusing as you try to create complex workflows through 2013. Originally, it was thought that Microsoft was going to add all of these actions to the 2013 workflow engine over time; however, no real advance has been made to do so.
Also, with SharePoint 2016 on the horizon, SharePoint Designer did NOT get an update along with SharePoint/Office 2016, and all indications are that it will not. I have yet to see an officially “deprecated” concerning SharePoint Designer, but based on the past history of InfoPath, it’s safe to assume this application will not be around past SharePoint 2016.
Third Party workflow tools
Third Party workflow tools have matured along with the SharePoint platform. The two biggest players in this space, K2 and Nintex, provide a deeper and easier to use interface than a SharePoint designer. (Note: These are NOT free tools). While each has their own strengths and weaknesses (which I won’t delve into on this post), both companies do an excellent job of filling the gap between the deficiencies and limitations of the native SharePoint engine. Plus, they also come with Forms capabilities that can replace poor InfoPath’s eventual demise.
Custom Developed Workflows
Finally, we have the most powerful, but also the most complex solution: Fully developed custom workflow solutions built on .NET and developed using managed code. This is not a solution you’ll find a business user creating or supporting; this type of solution will require development resources, and a full application lifecycle to ensure it can be deployed and managed properly.
But, the limitations of these types of workflows are few and far between, and truly allow you to automate your most complex business processes and tailor them to match EXACTLY how your organization would operate. The challenge is understanding your overall ROI on developing and maintaining these types of solutions, and it’s always my recommendation to only begin looking at these when it makes perfect sense from resource and cost perspective.
No matter what your business automation needs are as the SharePoint platform is concerned, there is a solution for it. But no matter what, make sure the solution you select is the right fit for your organization. And, always start with looking at your business processes themselves: If the process is so complex that no one can understand it, and there is no good way to automate it, maybe it’s time to find a better way of doing things.
Originally published on LinkedIn.