Hello everyone, how are you doing?
Before I get started on this post, I wanted to give a shout out to Matt Collins-Jones who ran a session at the D365 and PP User Group in Microsoft's offices in Paddington yesterday (28/02/2024). You can find these best practices in more detail on his GitHub here.
It was a great session and a lot of the content of this blog post is going to be me writing up the notes I took during it. I also wanted to take this opportunity to really get to grips with the new Power Automate editor, it's something I have been putting off for so long, and now I think it is time !
Flow Name
It's really important to name your flow in a way that helps anyone who is supporting the cloud flow, to a) be able to find it easily and b) work out from the title a bit about what it is doing.
Matt in his session, talked about having the table name at the start followed by some text to explain briefly what the flow was doing.
Description
It is also important to provide some level of description on the flows home page. You can do this from the main flow page, where the runs can be seen and click edit on the ...
In here, you can mention Azure Dev Ops bugs that you have fixed as part of this flow update, the date and maybe your initials to be clear who last touched the flow. I have heard flow version history is coming, but not sure when. Please comment below if you know :)
Renaming triggers and actions as you go
If you are in a position where you are supporting and maintaining flows, you need to really get into the habit of renaming triggers and actions as you go. This will allow someone coming to support the flow, if there is an issue, with a good starting point and the ability to understand triggers and actions.
Avoiding Unnecessary Loops
I have talked about this one in a blog post a while back. When a List Rows step is executed, an array of information from the table is returned. If you then try to use any of the dynamic content returned from that List Rows step, the action will be put into an apply to each automatically.
Apply to each steps are useful at the right time and place, but if you only want to return one value then put them in a first expression. This will not only make your flow faster to execute, but it will also half the amount of API calls you are making with this step.
Also, if you can, try and use the If expression when the number of options is lower than 4, this speeds your flow up and if you need more than that, then use the Switch action.
Notes
Notes can be very useful to explain a step or to put in a Power FX expression that you want people to read easily (or in my case, get back when you accidently delete it). The Notes section, can be found on the left hand side, after you have selected an action.
Scopes
Scopes are super handy, especially if you want to bunch up similar parts of a flow and to make the Flow editor load easier if you have lots of steps. One of the best ways to use scopes is in the try/catch scenario.
And in the words of Swing Out Sister, let's BREAKKKKKKKKKKKKOUT
For some reason, the new Power Automate editor isn't loading for me in this instance, I mean, I AM ACTUALLY trying to use it !
Try/Catch
When you have large flows, having some error handling should be common place in your logic. One of the commonest places I have used the try/catch method is when I am using the Office365 Connector. I use this quite a lot to get a person's manager, but this implies that Entra (AAD) is up to date and has that information stored inside of it. What if it doesn't? Let me show you !
In this example below, I have not implemented any scopes in the try/catch pattern:
If I run this flow... let's see what happens:
The flow fails because the email address provided does not have a manager associated with it. Let's modify it now, to include scopes for try and catch.
In this example, I am manually triggering a flow. In the trigger I am capturing an Email address. I pass this to the Get user profile action, to get the user's details from Office 365. Next I add a scope, I have renamed the scope to "TRY - Get User Manager" and then added the "Get manager" action from the Office 365 connector into the scope action.
As I explained above, scopes need to ensure all actions inside the scope are completed before proceeding to the next step in the flow.
We can now add another scope - let's call it "CATCH - If User Does Not Have Manager" and a Terminate action:
What we also need to do is use the Configure run after setting in the settings of the Catch step to only run if the Scope above fails:
We also need to Configure run after on the email action right at the end of the flow:
If you do Catch an error make sure there is an action to alert someone to the problem. Also, it's a really good idea to capture the URL to the Power Automate workflow that has failed. You can use the workflow() expression for that. Something that I didn't know that came up in MCJ's session is that there is also the results() expression, which is something that came over from logic apps.
I have gone back to this flow above, and added two compose steps, one for workflow() and one using result(), this gives you the details of the workflow run that has failed and the accompanying error message, for result(), inside the brackets you need to reference the scope that you want the result from. In this case it was "TRY - Get User Manager", so the result expression looks like this:
result('TRY_-_Get_User_Manager')
Child Flows
Child flows are amazing. The reason? Because, say you want to send an email using one specific template and populate that with dynamic content from the parent flow, well this is the way to do it without having to repeat these steps in each flow where you need it.
They are repeatable building blocks, which are more supportable, maintainable and scalable.
Custom Connectors
The benefit about custom connectors is that they can be built once and then shared across your Power Platform environment. The alternative to Custom Connectors, is building an HTTP action to call an API endpoint and then get a response back in JSON. This is not really enabling citizen developers to build in a low code way. If a custom connector is built, then you can paramaterise elements of the triggers and actions and provide a streamlined version of an HTTP call in a repeatable fashion.
The response from a Custom Connector call, also will provide it in a way where you can use it as dynamic content in further down stream actions.
Education
This is a big one. Educating yourself on Power Automate is a must, it's a huge area of the Power Platform and underpins a lot of application development within the space. There are so many blogs, YouTube video, LinkedIn posts on it, you really are spoilt for choice.
I have written a blog post, which keeps a list of various resources I go to, to get help when I need it, you can find that here.