“Having configurable flows is surely beneficial in the long term, but where do i place the Power Automate flow configuration?”
When building a flow, it’s a good practice to think about the involved moving parts. Which parts of the flow are fixed, that’ll probably never change? What will change if you move the solution to a different environment? How about reusing the flow on the same environment? Is there something the users should be able to change themselves? What should be easily configurable?
Answering these questions can significantly affect the flow architecture. Instead of having a hard coded flow where every change requires modification somewhere in the flow, you can change just the flow configuration. One place to adjust the flow functionality.
What options do you have for a Power Automate flow configuration?
Environment variables
If you’re using Solutions, as you should in many cases, you probably heard about environment variables too. Environment variables are exactly what the name tells you – variables related to a specific environment. The same variable you use in your flows can contain a different value on each environment – DEV, TEST, PROD, etc.
That’s what environment variables are great for – if you move the Solution between environments, you don’t have to touch the flow. The flow references the environment variables, working with the value it has on given environment.
Still, it’s the variables that are hard coded in the flow. If you decide to replace the variables, you’ll have to replace it everywhere in the flow, which is why they’re good for one-off solutions, but not so good for reusable processes.
You can have environment variables for text values, data sources, booleans, even a whole JSON.
However, keep in mind that it’s not user configuration. Managing environment variables requires higher permissions on the environment – you can’t tell the users to manage them themselves.
Good for:
– moving solutions between environments
– no need to touch the flow
Bad for:
– no user configuration
– can’t reuse flows on the same environment
Configuration in the flow
For flows on a single environment it’s not possible to use the Environment variables. As explained before, Environment variables are fixed per an environment – they can’t have a different value per flow. Yet that might be exactly the goal, to have similar flows just with a different configuration.
That’s also why I rebuilt the Approval process template, to make it easier to reuse. If it’s configured via Environment variables, you can have only 1 process per environment without changing the flow significantly. On the other hand, if the configuration is directly in the flow, it’s much easier to just change it in single place to modify all the actions.
After a discussion on LinkedIn I realised that the best way for such configuration is to use the ‘Parse JSON’ action. Enter the configuration in form of a JSON object and use it to create the schema. The benefit of this approach is that all the properties will be available as dynamic contents, and you can move the whole configuration in a Scope – no more variables before the flow!
It makes the flow development a bit more complicated though. While the environment variables contain direct references to data sources and allow you to use the standard actions, with configuration in the flow you might need a few HTTP requests.
Good for:
– reusing process on the same environment
Bad for:
– no user configuration
– trigger must be always configured manually
– modification requires touching the flow
– needs a bit of coding / HTTP requests
Configuration in a SharePoint list / Dataverse table
Both of the configurations before, let it be using environment variables or configuration object, are more on the developers side. It’s not a configuration that the flow users can or should change.
When talking about user configuration, it should be outside of the flow, available to the business users. An external source, mainly a SharePoint list or a Dataverse table when talking about Power Automate flow configuration. An example of such configuration might be steps in an approval process – instead of having them hard coded in the flow you store them in a list. It’s the flow that’ll get data from this list and act accordingly.
If there’s a change in the configuration the users can do it themselves, no need to touch the flow, no need to contact IT.
Reference to such configuration list should then be one of the environment variables or flow configuration properties.
Good for:
– user configuration
– no need to touch the flow
Bad for:
– core flow configuration, it’s no replacement for Environment variables nor configuration in flow
Summary
This article described 3 ways you can use for Power Automate flow configuration. If you’re building a one-time solution, something that’ll be deployed only once on a Power Platform environment, the Environment variables are the best approach. You can define all the data sources and global variables and the flow will behave differently on each environment.
For flows that’ll be reused, that can be deployed multiple times on the same environment, having a configuration object in the flow is the way to go. While you’ll have to touch the flow to change the configuration and the development might be a bit more challenging, you can easily reuse such flow many times.
But none of the configurations above allows users to configure the flow. If there’s something users should be able to change, you don’t want them to touch the flow. Give them an external configuration list instead to adjust the flow to their needs. The Environment variables or config object can then reference this user config list.