Power Automate - 4 Steps to Building a Flow

The interesting thing I found when asking people what their first experience with Power Automate was, they nearly all answered the same....

They opened it and started to build

They didnt go to documentation, they didnt complete a course, and they certainly didnt plan out what they were doing. And this is Power Automates biggest strength, and it's biggest weakness, you can build powerful solutions with zero planning. But just because you cantmm doesn't mean you should.

So this blog is all about the journey I take in designing and building a flow, I have 4 main stages:

1. Simple Design Document
2. Technical Design Document
3. Scaffolding Flow
4. Complete Flow

From a time and effort view the Simple Design Document (SDD) should be minimum effort (as this could highlight reasons to not continue). Technical Design Document (TDD) should have more effort, but the main bulk is in the Scaffolding, as this is the core of the development.

1. SDD (Simple Design Document)

The SDD is your top level design/plan, it allows anyone to understand what connections and scope of your flow. It does not have detailed descriptions or steps, but should be coupled with a Simple Goal Description to help explain what it does.

It allows the developer to understand any enablers needed (access/licenses etc), and is used for security and architecture meetings. It will also help generate any NFR's (Non Functional Requirments) required for the solution (like Authentication, Keyvaults, retention periods, encyrpted inputs, etc).

As an Example:

SDD

SGD
To track and classify Shared Mailbox

The SDD does not have to be particulary pretty, just functional, I created a Power App that automatically creates one from a few inputs, check it out here.

2. TDD (Technical Design Document)

The TDD is the next level up of detail. This document should show the detailed architecture of the project, the best way to think of it is the contents of your solution. It should list Connection References, Environment Variables and Flows. Each flow will have a description of inputs/outputs and what it does. Thought it will not go into the action detail of the flows.

The reason for this is 3 fold:

1. Planning connections and environment variables ahead can decrease development time significantly (anyone retrospectivily adding Environment Variables will agree)
2. Readability, any future developers will be able to see whats in the solution, why, and potential impacts on changing things
3. It allows you to plan out your build strategy, breaking the flow up into user stories, and creating a unit test plan

Although again it does not necessarily have to be pretty it needs to be easy to read and ideally consistent with other TDD's in your organization.

3. Scaffolding Flow

A scaffolding flow is the core of your flow without the 'bells & whistles'. It is designed to be a kind of Minimum Viable Product, although there are a few non negotiables that need to be included:

• Environment Variables
• Connection References
• Required NFR's

These should always be built in from the very begining, as trying to add then retrospectivily will introduce bugs and become a nightmare very quickly.

The scaffolding flow will often not be optimized and may generate wasted api calls. The goals is to get it working, as an example a loop within a loop maybe used, with the plan to replace with filters etc. Actions like Compose and Terminate will also be present to help with the development.

By building out the scaffolding of the flow we are able to:

• Build Quicker
• Learn About Potential Blockers
• Debug Easier
• Change/Adapt Our Plan

4. Complete Flow

This is adding on what we missed from our scaffolding flow. The main areas are:

Action Naming Convention
Naming all actions to ensure they explain what they do. This on is a little grey, as in some cases this should be done in scaffolding ie if you are manipulating objects renaming actions can break the expression. But in the main it should be done at the end (note this is not the same for variable naming).

Exception Handling
Exception handling should always be added last as the expectation of failed runs is high during development. It also allows us to build out a individual/shared/flow exception strategy (different parts fo the flow may need different exception handling, but we want to reuse as much as possible).

Future Proofing
Future Proofing is around making updates to the flow to allow easier expansion. This could be simple things like adding a config file instead of hardcoded values to changing from a Switch to a Lookup away for handling choices.

Optimization
Once a flow is working we can look at key areas of the flow to see if we can optimize it. This often includes:

• Swapping Actions with Expressions
• Consolidating Expressions
• Refactoring Loops
• Reording the Actions in the Flow to remove duplicates

Notes/Comments
Notes and comments should be added at the end to support future developers understanding of the flow.

These additional steps can seem convaluted and wasteful, with 'Just Building' being quicker. But taking these approach will save time in the long run and ensure your flows are built to be Stable, Susatinable and Scalable.

Building out patterns and templates will also help massivily, encourgaing your developers to work in a way that anyone can work of anyone elses flows.