5 Coding Standards for Power Automate

In this blog post, we’re going to take a look at 5 coding standards or best practices you can adopt when building solutions that include Power Automate cloud flows! We’ll go over big architectural tips and little debugging type tips! If you like this… READ MORE [https://lewisdoes.dev/blog/5-codi
data codes through eyeglasses
Photo by Kevin Ku on Pexels.com
In: Low Code Lewis Content 🚀

In this blog post, we’re going to take a look at 5 coding standards or best practices you can adopt when building solutions that include Power Automate cloud flows! We’ll go over big architectural tips and little debugging type tips!

If you like this content, make sure you subscribe for latest posts in your inbox!


Compose for debugging

My first tip is to get familiar with the compose action in Power Automate. Especially when using things like conditions etc where you don’t see the inputs to the various parts in a flow run, and rather you just see whether the condition passed as true or false, this is a super important and easy hack to debugging your flows!

You can read more about this tip in this post on the compose action – Compose in Power Automate – Low Code Lewis

Expression or Action

For a number of functions that we can write using expressions in Power Automate, there are also actions such as data operations which carry out the same operation. You might wonder, which one should I use? Why are there both?

The way I look at this is to think about who is going to edit or potentially develop further on these flows in the future? Do you have an entry level development team? Is this the scenario where you’re a maker in Power Automate and you’re handing a flow over to another maker in the future? Maybe the action is the best option here with it being more visible and easier to understand than an expression?

On the flip side, perhaps your development team is a group of solution architects and consultants with years of experience working with the Power Platform. It might be wiser to keep your flows more compact in this case if they’re potentially going to be complex anyway, by using the expression format which higher level devs will understand.

First() for List Rows returning 1 record to avoid Apply to Each

The next tip is to use the First() function in an expression when you’re having to use a list rows or GET action to get a single related record that sits on the many side of a 1:N relationship. If you always know that a list rows should only return one record, then we can work some magic here to avoid horrible apply to each loops especially if you’re then going to need to nest them which is even worse!

First let’s not just assume that a list rows has actually returned 1 record though. Even if you’re 100% sure it should, lets sit on the side of caution by implementing some error handling here.

We can use a condition after our list rows and say if the value of the body which is generally where our records sit if you’re doing something like a list rows or GET from Dataverse, only has 1 record in it, then continue, otherwise do something else.

To count the number of records we can use the length() function with the value of our outputs inside. Then we can compare this in our condition. If the length is equal to more than 1 then we should do something like send a central inbox a notification of corrupt data or records.

Avoiding the apply to each part…

The next part is avoiding the apply to each. For every part of our outputs that we want lets query the value but with a First() function around it. Things will look something like this…


So here we’re getting the first record from our list rows. Then we’re querying that record to get a specific property or column. Doing this avoids apply to each loops! 🎉

Hiding secrets

This next tip is to hide secrets in your flows by doing two things.

  • Use Azure Key Vault to store secrets as opposed to using hard coded values or environment variables.
  • Use secure inputs and outputs to hide secrets in your flow run history eliminating any chance of users or flow non-owners gaining access to your secret.

You can learn more about how to do this in this post on using Azure Key Vault… Using Azure Key Vault to store secrets for use in environment variables and flows

Using child flows

My final tip is to use child flows in the following scenarios

  • sub-processes
  • repetitive actions
  • cases where a retry might be necessary

You can read more about child flows, including how to use them in this post – Child Flows in Power Automate

An additional tip

Okay sorry there’s one more additional tip… but it’s less about what you do in building your flows but more about preparing your environment to create them with ease. This tip is to turn on the experimental editor in Power Automate settings. It works a lot better for a number of things so check it out!

Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.