Defining workflow requirements

Writing a workflow in Power Automate is a task that you can just get in and do, put it into production in your organisation and forget about it, right? That is the promise of Microsoft’s low-code solution and for some simple workflows, sure it works like that. But something more complex may require additional help. So how do you go about describing what you want in a workflow?

Let’s work with a manufactured example of approving an expenditure request.

Draw a picture

Drawing a process diagram for the typical path is a good start to document your workflow.

A diagram like this might not win awards in a competition for formal BPMN drawing, but it shows the steps in the process adequately enough for a third party to understand.

Review the pathways

A lot of workflow requests we get are for approval workflows, and clients are focused on “Here’s how it works if everything goes right”. But you also have to consider – what if it goes wrong? There’s a definition here of what happens if the expenditure is approved. But what happens if it is not?

Another fine point of detail is to look at the three options provided for evaluating the amount of the request, and who should approve it. Who approves an expenditure of $100? Or $1,000?

Consider any exceptions

There’s usually some outlying cases that you need to consider that don’t fit into the typical path. To identify some of these, start by looking at the roles involved. In the example here, if the CFO wants to spend between $100 and $1000 dollars, then can they approve their own request? Does anyone have the ability or need to review the CEO’s request to spend $10,000? If the person’s line manager is on holidays, who should the request go to? How you want to deal with this kind of detail can be the difference between a simple and complex solution.

Define each step

Now that we’ve got a big picture in mind, let’s just have a look at each step we’ve defined above in turn.

For each, we want to know:

• What happens during this step? What happens now provides important context information, or what you intend to happen in future is a key requirement.
• Who performs this step? Consider in the last step, “the person who submitted the form is notified”. Who does this – a person or the system?
• When does this occur? Our example is about steps that require human intervention to follow the process, but maybe you have a step that needs to “Occur every evening”, or “Once per week”.
• Next steps? Now that you have all the paths defined, let’s make sure we understand what criteria is required to send the process down a particular path.
• Who needs to know about this? Does someone require notification that an action is required of them? Are you going to bombard the person with email? Or do you post in Teams?
• Is there a time limit for people to respond? Does this lead to an escalation, or just another notification that there is something waiting for their attention?

Provide additional information about the overall process

Some overall details not covered by a picture are also relevant to defining a workflow.

• Will someone need to be able to monitor where all the requests are in the process?
• Can someone intervene in the process, e.g. if an individual is absent?
• Who will fix the process if something goes wrong? Do you need to look for ongoing support for the workflow as well as the initial development?

What happens next?

If you approach a developer with these details documented and agreed, you can be confident that any estimate they provide you with is more accurate.

Biggest challenges with workflows

The misconception that because a workflow look like a flow diagram, they are simple.

The processes that a workflow supports can have many paths and, although the variance to the main path may be small, each variance needs to be accounted for.

Workflows are still a form of development, so are subject to all the same technical challenges and unknowns that are prevalent in other development. During their creation they need the same attention to detail, rigorous testing and a plan for how it will be supported once it is in use.

Over automating is real. 100% automation requires every scenario to be accounted for. In some processes there is value in that level of automation but often times it drives the costs for the automation well over the value returned. Consider the real need for “System does this via workflow” against “Person intervenes in this situation”.

Summary

A simple no-code solution from Microsoft can get complicated if it needs to be ‘100% automated’. To minimise the surprises that you could encounter along the way:

• remind yourself regularly to keep it simple
• go through these requirements steps
• make pragmatic decisions and compromise around 100% automation.