Taking the covers off SharePoint workflows

13 August 2013

You have probably heard a lot about SharePoint workflows and business automation—and those features sell a lot of SharePoint deployments.

But there is more to it than just waving a magic wand, clicking a few buttons, and watching as your documents move themselves along with seeming self-intelligence.

There have traditionally been three ways to handle SharePoint workflows. Let us look at each of them in a little more detail:

Creating very basic SharePoint workflows SharePoint in the box, or in another words, as part of the set of functionality you get in the base product itself. This workflow type is especially easy to create given you can start and customize these basic workflows right from within the default SharePoint interface. This is the basic “when this happens, move this here” type of workflow. The downsides of this approach are the limited configurability available for these workflows, and perhaps more importantly, the learning curve for your non-power users to even get started with workflows, even the most basic. This area is really of limited utility.

Workflows you can create and design through the add-on SharePoint Designer product. Your power users probably crave more detailed SharePoint workflows than are allowed with the in the box tools, and the freely downloadable SharePoint Designer product satisfies this area. With a bit of training, sharp intermediate users can create workflows a step more complex than with the basic tools. However, only sequential workflows are supported using this model, and the workflows created with SharePoint Designer are designed only to fit within the environment in which they are deployed; it is difficult to port them as a solution to other environments.

Workflows you develop in managed code using Visual Studio or another integrated development environment (IDE). This is where the really juicy work begins, where you can take advantage of all of the capabilities of Windows Workflow Foundation (known as WF) and also create stateful and sequential workflows, in addition to being able to port your workflow solutions across to different environments. However, if you are not already a Windows developer, this requires a rather intensive training regimen, meaning you will probably hire out a developer or consultant to build this for you separately at great expense. Additionally, any changes essentially require redeployment of your workflow solution, and since these are generally portable, you have likely deployed them in multiple environments, necessitating a redeployment in every environment you have put them in—a lot of work for even minor improvements or redesigns.

It is really this last point that deserves some consideration. Creating SharePoint workflows in the box or with SharePoint Designer gives you minimal functionality—and that might well be enough for a small office or a tiny team with just a few people that want to build out a solution quickly within minutes. But much of SharePoint’s vaunted reputation for creating high powered workflow automation is based on creating code based workflows within Microsoft’s programming languages using Visual Studio. The power you get from creating and developing custom workflows in a language like C# or Visual Basic comes at the cost of actually learning those languages, and in most cases I have seen, the SharePoint users hoping to build workflows are power users trying to solve real business problems, not developers eager to build “Hello World” into everything they possibly can. (Nothing against developers, of course.) There are just two different audiences here for SharePoint—the people who need the capabilities, and the people who are capable of making them.

Another point of frustration is that these powerful workflows are created inside containers called solutions. This seems good, until you need to make a change, at which point a typical change management process would kick off, requiring packaging, testing, deployment, and monitoring to make sure nothing horrible happened or no other technology was affected by the change. This is par for the course when you are first setting up a system, but what happens when your stable solution needs a change? What if your business process itself goes through a minor revision? What if a new client needs something that could easily be part of your workflow? Out comes the phone, and you call the wizards, who then have to develop the code, package it, test it, deploy it everywhere, and monitor it to make sure nothing has been broken. If you are outsourcing your SharePoint workflows development, then this change exercise has cost you a few thousand dollars. Now you know why consultants roll their eyes when you say, “This should just take you a couple of minutes to do!”

Ultimately it is up to you to realize that SharePoint workflows can be quite powerful—and quite expensive and complex and not flexible to change.