Power Automate Best Practices

Perhaps you read our previous blog that outlined some tips on how to build your first “flow” using Microsoft Power Automate. Or, maybe you read the blog we posted earlier in the week that talked about converting your SharePoint 2010 workflows to flows in Power Automate. The interest in Power Automate is increasing as organizations seek out ways to leverage Microsoft 365 to automate processes, streamline workflows and create a modern workplace that enables workers to stay productive from wherever they may be.

Kiefer Consulting has been building workflows in SharePoint for well over a decade and we have been testing the limits of the Power Automate since it as released as Microsoft Flow in 2016. In working with Power Automate, we have developed the following best practices for creating and maintaining Flows.

Simple Flows follow a repeatable pattern

Simple Flows should follow this pattern: 

  • Trigger 
  • Initialize a Constant variable object (which contains all constants) 
  • Initialize variables 
  • Test to see if the Flow should run (did the status change? Did the record change?) 
  • Perform processing/preparation 
  • Update Record(s) 
  • Exit

Successful Flow design is to get in and get out.

Successful Flows avoid long “Inflow” conditions.  where possible and practical, the Flow should start, process and exit, keeping the time in the Flow to a minimum.

All Flows used by an organization should have more than 1 Owner.

If a critical Flow only has one owner, and that person leaves the organization, the maintenance of that Flow will become very difficult.

Always test if the Flow should run.

At the top of a Flow, add code to test the current item to see if processing should continue, and terminate if it should not.  Since updating the current item may trigger a new execution of the Flow, this should be done to avoid endless Flow executions.

Banner to download a free non-technical white paper on how to get the most out of SharePoint

Use a Naming Convention when naming Flows.

Develop a scheme to name Flows.  This makes locating and maintaining them easier.  The more Flows you have the more critical this becomes. For instance, the following Flow, to notify the Information Technology department of a new hire runs on Baumann and Peterson Inc.’s (BPI) Employee List. “BPI: Employee – New Hire Notification”.  Another Flow running on the company’s Lease Agreement list to update contract values is called “BPI: LeaseAgreement – Update Contract Totals”

Label every action, label them early.

Flow creates a default name for every action. For example, the default name for the Initialize Variable action is “Initialize Variable”.   If you use this action again, the default name used for the new action is “Initialize Variable 2”, and a third use will be “Initialize Variable 3”. 

The default name should be updated immediately for the following reasons:

  • The action’s purpose should be clear so that the action itself does not need to be expanded and examined.
  • New actions will not be named with an appended number
  • Flow Checker will point you to “Initialize JSON Input” instead of “Initialize Variable 4”
  • If an action is renamed, Flow does not do a perfect job of renaming all the downstream uses of that action.
  • Downstream usage of the actions is much easier and self-documenting.  It is easier to look up an action named “Convert termination date to local time in mmddyy format” than to look up “Compose 6”.   

Every Condition Statement should point be phrased in the affirmative

When the “Condition” action is used, it should be renamed to indicate the test it is performing.  “Condition” actions should be renamed and phrased in the affirmative, where the branching answer, either Yes or No, clearly answers the question.   The Flow Results does not show the condition itself, only the result, therefore the title of the Condition is critical. “Condition” actions should NEVER use the generated action name (“Condition X”). Since Flow always puts “Yes” on the left and “No” on the right, the question should be phrased appropriately (without a question mark) and reference the underlying if statement: “Has maxLoopCount been Exceeded” or “Is maxLoopCount greater than 10”  as opposed to “Condition 5” (too generic) or “Check for Loop Count” (the condition cannot be answered with a “yes” or “No”) 

Use scopes to group a set of work. 

Often, two or three Flow actions are required to perform a single set of work.  If you need to add two values together, then test to see if the two values are greater than a limit, and if so, terminate the Flow, these actions should be grouped together in a scope and the scoped renamed to “Terminate workflow if the loop execution exceeded the limit”.  This makes the Flow easier to understand and these details can be visually abstracted when the scope action is collapsed.

Limit the amount of “Drilling Down”

Avoid nested “Ifs” by terminating the Flow (where appropriate) if the condition is false.  This makes the Flow read better and you don’t need to drill down into the “Yes” result.  Good Example:  If the status is equal to Complete then terminate. Request HR approval.  If HR Approves send approval email, else send rejection email.

Bad Example:  If the status not equal to Complete, then start an approval action. If HR Approves send approval email, else send rejection email.  Results wise these are the equivalent, but in the first case, the two actions are siblings, and in the second case there is the HR approval is nested within the first condition. Reducing nesting makes the Flow much easier to read and making expansion not necessary.   

Nesting should be avoided where possible because: 

  • There is currently an 8-level nesting limit on actions. 
  • To maintain nested actions the actions must be expanded.  The more expanded actions that appear on the screen, the slower the design surface reacts.     
  • Nested actions take longer to process through the debugging surface. 
  • Nested actions hide details about the business Flow so are less expressive. 
  • It is easier to debug an un-nested step than to debug a nested step. 

Name variables using camel case.

Lowercase first letter of first word, upper case letters of all other words. No spaces.  This makes variables stick out in the action description.  It is much clearer to say “Initialize maxLoopAmount” in the action name, than “Initialize Max Loop Amount”.  

Flow has no source control.

Flow has no source control, before making modifications to a Flow you should export and save that source in your source control library (or a SharePoint list) for backup purpose.

The more actions, the more cumbersome. 

The bigger the Flow is, the more cumbersome it is to work with it in the designer surface.  The surface takes longer to load, and actions become harder to locate.   As a corollary, the bigger the Flow is, the more cumbersome it is to view the “Run History” as lots of data must be loaded. 

We can help

Leveraging Power Automate is an opportunity to streamline processes and improve efficiency. We can help you get started. Kiefer’s team of consultants can help you leverage the tools that are empowering the Modern Workplace. Contact us to learn more about automating workflows and leveraging the investment in Microsoft 365.

Archives

Follow Us

Leave a Comment

Your email address will not be published. Required fields are marked *