Many simple workflow solutions are linear in nature. Using a document review as an example, the simple workflows allow a reviewer to make a decision that is either to approve or reject the document. If they reject, the original author gets informed and the workflow stops.

In reality people do not work this way and a document review often involves multiple iterations and reviews until everyone is happy with the document. What the workflow needs is a command to send the document back to the original author for rework but with the simple solutions this concept does not exist so workflow developers end up building complicated loops. I’ve provided an example below using Nintex of how to do this. NB do not copy this example – it is horrible and there is a much better way if you continue reading!

In the example you can see that the workflow designer has to set an approval status. If the status = work in progress (WIP), the workflow will loop as many times as is necessary for the reviewer and the author to perfect the document. Then once a decision has been made, the workflow has to branch again to perform the actions necessary based on the outcome. It is hard to understand and adds quite a few unnecessary steps. What happens if the process changes to include two reviewers? The workflow becomes a nightmare to manage! Below is a screenshot of how you’d do it.

Even this workflow is very limited as any rework is always sent back to the original author – there is no option for the second reviewer to directly send the document back to the first reviewer. You can see how quickly this type of approach gets complicated. It is also inefficient as the Send for rework tasks and following actions are identical. If the task needed to change, the workflow designer would need to update both tasks.

Branch by Stage

Lucky for those of you using Nintex we have “Branch by Stage” as it is known in Nintex Workflow Cloud or “State Machine” for the versions of Nintex running on SharePoint. Here’s how the same multi-step approval process would work using this concept.

It is much easier to understand, much easier to implement and it also provides a lot more functionality! The thing that I like the most about this construct is there is no duplication of that duplicate rework step in the looping example. It is also very simple to add another outcome for reviewer 2 to send the document back to reviewer 1 instead of the original author whereas with that looping example, it gets messy and hard to follow.

Dynamic starting positions

Then we get into examples where the starting position is dynamic. E.g. we evaluate whether the reviewer should be reviewer #1 or #2 based on some conditions e.g. the type of document / the dollar value / the location etc. It’s as simple as setting a variable based on the condition and then telling the state machine to start with the value of that variable.

Flexible, Robust Workflows

This same concept also enables us to build more robust, reusable workflows. Here’s another example of your classic employee on-boarding experience. At a high-level there are some major tasks that need to be performed: create their employment contract and then if they sign, provision IT systems, provision a mobile phone or other equipment such as a laptop etc. Arguably each one of those high-level tasks could be a separate workflow and those individual workflow don’t necessarily need to be called during on-boarding e.g. you might need to set up someone with a mobile phone at any time. The branch by stage action enables us to easily arrange and run these independent workflows.

We can take this a step further. Let’s say something broke during the provisioning of the systems. You don’t want to ask the new employee to sign their contract again because that would be inefficient (and annoying to them) but using the Starting Branch example we mentioned earlier, you could start this workflow directly from the provisioning systems step. Using the power of the branch by stage action you can make your workflows more resilient and flexible and that is a good thing.

Next time

In my next blog post I’m going to delve deeper into some useful techniques to make a review cycle even more powerful. I’ll show you how to send comments to other reviewers, edit data at any stage and delegate tasks. In the meantime, I encourage you to check out the Branch by Stage help topic.  It graphically shows how a workflow could move between stages and links through to some examples that you can try yourself.

Stay tuned to this channel!