Power Automate, The Direct Methodology Part 2

The Direct Methodology follows the design principles of:

• Use less actions
• Have less paths

I went into full detail of what it is in a previous blog (I recommend reading it first).

In that blog I also talked about techniques to get from from Christmas Tree to Direct, specifically the Golden Rules:

• Expressions before actions
• No duplication
• Break up large flows into child flows
• Avoid high nesting levels
• Terminate early
• Only one end path

But one of them I did not go into much detail, and that is 'Break up large flows into child flows'. This is a key design principle that can help ensure your flows are 'Direct', so this blog is all about how and why.

Why Break up Large Flows

There are lots of reasons why it may seem that keeping your solution in one flow is better, things like:

• Easier to Deploy
• Quicker to Develop
• Uses only one Flow Only Licenses (if applic)

But I would also say there are a few reasons to, most namely:

• Easier to Read post Development
• Easier to Test
• Easier to Update/debug
• Avoids Slowdown of browser in Development
• Reusability

and it is the last one that is crucial to the 'Direct Methodology'.

Power Automate has one design constraint compared to other solutions like Dell Boomi (and UI Path, Blue Prism, etc) and that is it is linear. You can only move in one direction, down. This means that action blocks can only be used once, which is not efficient, and goes against our 'Use less actions' principles. This is where Child flows come in, as they allow the flow to call the same action blocks and return back to its linear path.

This linear issue is also magnified by branching, as any action block used on both branches needs to be duplicated (unless smart ordering and moving the block to either before or after the branch, but this is not always possible).

Without Child flows every branch and every repeat instance of an action block would require duplication. This becomes a particular issue for 2 main reasons:

Updating
If you need to make an update to the action block you have to do it across all instances, this is time consuming and open to human error generating inconsistencies.

Readability
Reading someone else's work, or just coming back to your own after a while, can be challenging. Having long flows makes it hard to read, and having duplication increases that. The developer doesn't know what blocks are doing the same thing and what are different.

Example

I wanted to give an example, so I created this use case:

The automation is designed to manage a shared mailbox, there are multiple different categories of emails, each category follows a different combination of features.

These features are:

• Request approval
• Notify right team
• Move Email to required folder
• Save Attachment to required location
• Add to tracker

The categories are:

Delivery Update
Move Email, Add to tracker

Invoice
Request approval, Move Email and Save Attachment

Complaint
Add to tracker, Notify Team

Unclassified
Move Email, Notify Team

Enquiry
Add to tracker

---

So if were to follow branching logic we could quite easily end up with multiple duplication:

• Notify Team x2
• Move Email x3
• Save Attachment x2
• Add to tracker x3

But if we move all the reused actions into child flows we get a simpler flow.

Although this is not a perfect example it highlights how reusable action blocks can be used.

How to Break up Large Flows

Breaking flows up into Child flows is not as simple as it may sound, this pain is often why people don't use them. Trying to add them retrospectively causes no end of issues, and it can feel like we are breaking a working process for no value. But the key to good development is planning, and implementing Child flows from the start is significantly easier.

A SDD (Simple Design Document) is the best starting point, as this is where you understand the functional aspects of the flow.

The SDD gives you a helicopter view so it is ideal to see duplication and possible reusability.

The next step is to build out the parent flow, you should never start with Child flows. This is because you want to ensure the Child flow is suitable for all the use cases. If you build it first you will be continually going back and updating it, simply drop a compose as a placeholder, adding inside it a list of inputs and outputs.

Once the parent flow is complete review the composes to gather all the inputs and outputs required, its as this point you might realise that a certain use case can't use the Child flow. Remember trying to overload a Child flow to make it do multiple things invalidates the whole point. The Child flow should also be simple and cover one function, so that any future developer can easily see what it does.

---

Sometimes the Direct Methodology can feel like unnecessary work, making the development process take longer. But building to be scalable and sustainable is key, and investing in the build at the beginning saves time and stress in the future. Additionally like all techniques, the more you do the easier it becomes.