Developing Top-Down Code Free Workflows using SharePoint 2013 and Nintex Workflow

I’m fortunate to be part of the platinum business partnership with Nintex. Over the last few years Vantage 365 has made no code workflows using Nintex Workflow one of their focus points. Of course when we needed to, we would also do the hard core development but if it is possible to avoid then Nintex Workflow is often a nice solution, giving the end user a chance to automate things.

There are however many different ways to create workflows and I have found many examples where a small workflow has turned into a large ugly beast. This article describes how to keep control over your beasts.

The Basics

Many workflows are a set of steps following each other.

Then many conditions, ifs, loops, and more steps are added and the beast is appearing. Not too much of a problem today but next month things are getting a bit harder and once the original developer has left the organisation the ugly beast is still there.

So how do we solve this? Firstly I’d like to list a number of best practises for developers.

• Self-documenting code
• Top-Down programming (first the larger picture then the smaller detail)
• Bottom-Up ( make the detail available and then use this during the implementation of the larger issues)
• Encapsulation (Hide the detail, when looking at the larger problem)
• Functions/Procedures should only do one thing
• Handling Errors and create robust code

So if developers follow the above guidelines why would you not do this when you go for No-Code Workflows?

Self-Documenting Code

Each step in Nintex has 4 labels.

• Top – task name. In general I leave this as it is
• Left – By default this is blank. I set this to the object that I’m doing an operation on. E.g. Variable to be set
• Right – Also this one is blank by default. I use this to include the value that I’m setting variable to.
• Bottom – Description of the task. E.g. Set the status value to Completed.

Top-Down programming

Now we’re getting to the good parts of this article.

Even though I’m mainly focussing on Nintex, the ideas that I describe would also be relevant for other workflow engines.

Nintex can like many other engines use State Machine workflows. State Machines have a starting point where the current state machine is checked and then steps associated with the state are executed.

At the end of each state a Change State needs to be included to make the workflow move to the next state.

So a typical flow of states could be:

Initialize -> Collect information -> Approve Information -> Get 2nd Approval -> Complete the workflow

All easy and no real need to start a state machine workflow? Simply create 5 steps I hear you think. Why make things difficult?

The answer is business requirements and exceptions.

The easy 5 steps mentions below work fine as long as we’re only talking about approval, but what if …

• The approver needs additional information entered by the originator
• The approver rejects the information
• The information entered is invalid and a workflow errors
• …

This is where for every workflow that I create I create a State Machine. Typically I would use the following states

• Initialize
• Collect information
• Approve Information
• Get 2nd Approval
• Complete the workflow
• Error
• Request more information

Each one of these states looks like their own little workflow. By keeping each state a simple set of steps the workflow is kept simple.

Make sure though that every branch of your state machine ends with a state change.

Also there should never be any step following a state change. Also do not include any End workflow steps within the State Machine. Even though the workflow will end gracefully the state machine does not and in the workflow history the state machine will show as not completed.

Encapsulation

When users view the workflow history they will still see the big ugly beast if you follow the above steps.

Yes, a bit more organised but still many steps, which may be difficult to understand. So how can we hide all the steps and make the workflow look even less complicated?

Within each state an Action Set with all the steps for that state should be included. So that a single step is a container for all the activities within that each state.

When Action Sets appear in the workflow history they will appear minimized. Therefore each state will simply appear as a single step. If the user wants to see the details of the action set then that is possible however by default the details are nicely hidden away.

Error handling

One of the annoying things with workflows is that they sometimes error. This may be down to bad ‘no-coding’ but it is difficult to catch every error during development. So when things go wrong what is the best way to recover?

Most likely the workflow will first need to be fixed. Then the workflow needs to be restarted. Problem fixed?

No, because the issue might still exist in previous instances of the workflow. And also what if the issue appears after the first approver has already approved the document. Does he/she have to approve the workflow again?

The way to solve this problem is by creating an Initialize state (The state can be called anything you like of course).

In the initialize state the workflow needs to look at a status field on the item. Most of the time I’m adding a status field to the item/document.

This status field can be a simple text field and is set at the beginning of each state of the state machine. This means that if a workflow is restarted the status field tells the workflow during the initialisation where to continue.

If the status is not set then it’s most likely as the workflow hasn’t run before. Now all I have to do is use a switch activity that checks the status and sets the appropriate State Machine state with a Change State activity

See also my post about error handling in Nintex

Use Functions

A number of weeks ago I developed a Nintex workflow with 10 approval/review levels and during each approval step a request for more information from the originator could have been requested.

A nice additional benefit of the approach described in the error handling section of this article is that during the workflow if additional information is requested from someone. The workflow status can be used to find out who requested the information.

This makes the request more information state behave a bit like a function in traditional programming languages. Once the Request more information has completed we simply go back to the initial state of the workflow.

The initial state of the workflow then looks at the item status and makes sure that the workflow continues from where the additional information was requested.

Conclusion

State machines are a great way of keeping large workflows clear and simple.

If  you need any help developing your Nintex workflows please feel free to contact me either through the Vantage 365 website or through the contact details on this blog.