Guidelines & Best practices – Power Automate (flow)

Posted on by

Introduction

The purpose of this post is to outline the Governance guidelines and best practices to develop and configure a Power Automate (flow) on SharePoint Online and Office 365 environment.

Points/Limitations to note

The below points are to be considered while or before developing or configuring a Flow. This information also highlights the limitations of a flow.

Flow duration
Flows will stop running after 30 days, and there is no standard way to keep trace of them. Sometimes this might not be an issue, but if the flow is more complex or longer process, this does become a problem. Flows can be the strings that hold communication between services together, and could find business solution breaking for longer duration Flows.

License and connectors
Power automate license and connectors are at cost impact. Consider the below before planning to implement any external/internal integrations with in a flow.
• Review and validate the pricing factor before integrating with any connectors.
• Number of runs allowed by the running account

Nesting
There is currently an 8-level nesting limit on actions.

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

Action Limitations
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 clumsier it is to view the “Run History” as many data must be loaded.

Opt-in to notifications
Notifications are one of the most popular uses of Power Automate.
For example,
1. To get an email when someone uploads a new file to SharePoint or posts a new response in Microsoft Forms.
2. To get a weekly status report of work items in Azure DevOps or charts in Power BI.

One of most common types of internal flows was daily or weekly reports of SLAs, errors, and usage metrics from Azure Data Explorer, sent to individuals and teams. These types of flows are great for a number of scenarios. However, keep in mind that not everyone is interested to get yet another email. These often quickly end up as Outlook filters, and suddenly flow runs emailing no one. Before adding a distribution list to an automated email, make sure that the information is either need-to-know, or that the distribution list allows users to individually remove (and add) themselves.
If such a requirement faces off for checking these metrics on an ad hoc basis rather than as they come in, the data may be better off in a dashboard (e.g. Power BI or Azure DevOps) so that it is available on demand.

Check Available Templates
Check for any existing templates, which might match the requirement before starting to create a flow.
Power Automate Templates: https://us.flow.microsoft.com/en-us/templates/

Document your flow
Consider documents to describe Complex Business Apps technically.
Provide technical documentation so that management or a future consultant can adjust the product. Write down as much context as possible in the flow itself. Provide flow with a description and comment on individual actions.

  • Monitor the flows and think about other licensing models
  • Consider a flow you have created might be through the API Calls of the month in no time. Microsoft offers several ways to fix this problem.
  • This allows purchasing an additional subscription. Thus enables to increase the number of API Calls for the (service) account.
  • A Power Automate per flow plan to buy an x number of flows that allow making many more API calls per month.
  • Finally, there is also the possibility to convert flow to Logic Apps. It is easy to export your flow to Logic Apps. This solution is a little better with large numbers in rest Api calls.

Development Best Practices

Label/Name Flow

Appropriate labeling also is good practice for flows shared between stakeholders so that anyone can easily understand what each step of a flow does.
In general, labeling/naming each step is a best practice.

Naming Conventions

The below notation should be applied while developing or configuring a flow.
• Flow
Development : DEV_ Delete_PDF
Produktion: PROD_ Delete_PDF
• 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”.

Name your actions
Giving generic names to the actions may not be such a big problem for a small flow. However, as the flow becomes more complex it is more and more difficult to see what exactly is what.
• Even data usage from the actions in other actions, it is quite difficult to distinguish if no clear names are given.
• Adjusting these names afterwards have a chance that references in the Flow will break, because they use these titles underwater.
• It is also easier to give an action a good name right away if you remember exactly what it does.

Use scopes
Use scopes to group a set of work. Often, two or three Flow actions are required to perform a single set of work.
Example use case:
Consider a requirement to add two values together, and 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.

Use error handling in all your flows
From time-to-time, things do not work out exactly as expected in the flow — that is where error handling comes in.
With error handling, there is a possibility to define ‘N’ number of steps to run after the failure of an action. This powerful new feature will ensures to run most important business processes inside of Microsoft Flow.

Avoid infinite loops
Example use case:
Consider a workflow to start when an attribute is updated, and then have it update that same attribute within the workflow’s logic. This update action will continue to trigger the workflow that updates the record, which then triggers the workflow that updates the record again, and again—to infinity (but not beyond).
• Any workflow will include logic to detect and stop these infinite loops and return error messages for when they occur.
• As such, process will fail, and will be able to go back and fix the workflow logic—but it is always good to know why and what causes infinite loops to avoid them in the first place.

Avoid nested loops
• 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.

Avoid variables (in branches)
In parallel branches when variables are used, then branches will wait for each other. This have an impact on the performance.
• If possible try to use compose actions instead to hold information.
• When variables need to change throughout the run of the flow then variables may be used, but think twice before using the variables.

Generic Use Templates
If many of workflows being developed or configured are similar and if there is an intention to create more workflows that follow that same pattern, save workflow as a template.
• Use that same template when creating similar workflows which saves from entering all conditions and actions repeatedly.
• Create Process and choose new process from an existing template!

Add Comments
Add comments to actions. It does take a lot longer to develop flows therefore you could leave it to the minimum. It is however important to leave the comments when actions need further explanations

Test your flow as you build
Test flow steps through the development process.
• Troubleshooting flow is much easier while testing the flow at discrete steps of the process.
• In addition, each subsequent step is impacted by the previous step, so it should always be a best practice to test the flow while creating the steps.

Add redundant owners
If there is a flow, where entire team uses it, refer to the following guidelines.
• This applies for Non Service Account Flows
Make sure to add a couple co-owners so that they can update the flow in your absence. Whom you add depends on how the flow is used. Probably at least your direct manager who can act as your proxy. Maybe your manager’s manager if all of their reports are relying on it.
• If the group is large enough and/or has many team flows, consider creating a Security Group of 2-3 people who are willing to set aside a small amount of time to keep an eye on all the team flows.
• Do not add your entire org as a co-owner
• Also, keep in mind that the access applies to not just the flows themselves but to the connections, they use.
For example, if a flow sends mail from a shared mailbox, make sure that the co-owners have access to that mailbox in case they need to recreate the connection while you are in absence.

Add a signature
When using automation to send emails and post messages, let people to know where it’s coming from.
This is especially important if the automation works with people outside organization or external systems where the recipient may not be aware of flow.

Use a signature like “Sent with Power Automate. Contact with questions.” You may also find it helpful to link to the specific flow so that you can find it quickly if someone forwards you the email.

Deployment


Configuration Account
If a user has created Flows under his own account and then leaves the service, the flows will no longer work. The flow and connections within that flow are all under the user name. If user no longer exist within the organization then the flow will break.

Therefore, move flows to a specially created service account. You can do this by exporting the flow to a *.zip file and then importing it with the service account. In this way, the Flow and connections are registered to the Service account. Your flows will always work and you can manage them more easily from one account.

References

Websites

Blogs

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.