DEV Community

Cover image for Power Automate- Orchestrating Your Flows
david wyatt
david wyatt Subscriber

Posted on • Edited on

Power Automate- Orchestrating Your Flows

Power Automate is a brilliant example of no code, easy to learn, powerful, and brilliant at scale. But I'm starting to see more and more monolith flows. What's a monolith flow, simply put a massive flow, and I don't like them.

Monolith processes are kind of the curse of no code. Because the building blocks are generally small and universal, solutions can require many blocks, arranged in ever more complex ways.

Back to why I don't like big monolith flows, well there are a few reasons

1. Web based

Unfortunately web browsers can suffer with too many items on the dom, and complex flows have so many divs and other elements it can impact how the browser performs. If you open a big flow, and open up every action/step you will see massive slowdown, almost to the point where it's unusable.

2. Debugging

Debugging is never fun, but long complex flows are a nightmare, trying to identify the cause of a bug is horrible, with small flows tracking cause and effect is much easier.

3. Testing

Linked very much to debugging (and a massive oversight from Microsoft) there is no run from or run too. Incase you don't know what they are in Blue Prism and other RPA tools you can set temporary stop points or start points. This allows testing small parts of your automation. In Power Automate you have to test the entire flow, you cant even cancel and see what had run. Its ridiculous but a 100 worst in big flows.

4. Efficiency

A bit of a generalization but in my experience Big complex flows often suffer from 2 areas of inefficiency - duplication (same code sequence replicated - which is difficult to maintain) and unnecessary looping (actions/steps inside loops that add no value but use up Power Platform API calls).


The truth is we need to have a full design plan before we start any development, that might mean certain complex solutions are not right for Power Automate, but when it is right the right design plan is needed. There a few different templates we can use.

Sequence Chain

Image description

The simplest way to break up your monolith flow is into a sequence flow, with each flow calling the next in the chain. The sequence can branch out in parallel where needed and even incorporate branching logic, calling different childflows based on conditions.

Its main draw back is it can still become hard to manage when it gets too long. As tracking failures requires checking multiple locations. I generally only recommend for short simple flows, up to a chain of 3 flows.

Sequence Hub

Image description

The sequence hub is similar to Sequence Chain but fixes its main drawback by having a hub flow orchestrating all the child flows. As well as having the benefit of being easier to track, it allows more reusability through a function like approach.

Human in the loop

Image description

This one is a bit of a niche but has some very good benefits. Using human interaction to trigger the next flow e.g. uploading a file in the next library.

The main benefits include all the above and the avoidance of solutions if you don't like them (As childflows must be in a solution). An additional benefit is moving possibly complex logic out of the flow entirely (sometimes a human is just more efficient). Another great use of Human in the loop chains are for an approval processes.
The approval action is a fantastic action, but can easily force multiple flows into one. Breaking flows into separate flows and enforcing human interaction is just the same as an approval flow.

Workqueue

Image description

Probably the best solution for large complex processes is workqueues. I've done a full blog all about workqueues (link at the bottom), but the general idea is to create a central list/queue of tasks. Each task is the picked up by different flows depending on the status/tag of the item.
It has all the benefits of a sequence flow with the addition of a built in logging system that has benefits like tracking and forecasting.
The only downside is it adds an additional level of complexity (status/tagging) and it breaks the solution out of Power Automate, as an external database or list is required.


As you can see there are lots of ways to break up large flows in to manageable chunks. More and more pro code development is moving away from monolith solutions to micro services, and just because its no code doesn't mean we don't get the same benefits.


Further Reading

Top comments (0)