Anyone who has been bitten by the Flow-Bug knows exactly how it feels to be in the zone. There you are, creating mad logical automations, with countless parallel branches, varied connectors and actions upon actions when suddenly, it dawns on you:
“Oh, this is gonna be a PAIN to update after go live when we have to push these things to our test/prod environments…”
…and then you cry a bit. Quietly. To yourself.
(No shame in a good Automate sob now and then! Just means we’re workin’ out our logical brain!)
Lucky for us, there’s a concept called the “Environment Variable” that will help a ton when it comes to our dev cycles and managing our flows!
For full documentation on Environment Variables, click here. I’ll try and give my best summation of how they’re used:
As the name would suggest, they are quite literally variables that we can define which are meant to replace specific pieces of data that are unique to that org. Some examples would include:
- If a parameter needs to change across environments and cannot (should not) be hard-coded i.e. a URL that points to a different resource in DEV and PROD environments (HOWEVER: There’s a caveat to this)
- If your customer is required to provide an input value for something environment specific
- Like with a global option set, if you need to make a change in one place but have that change be accessible instantly in multiple places
- Updating configuration values without modifying code or if the person managing the configuration is not familiar with coding. (This has been a fairly common usage for our clients so far)
The caveat to the URL parameter that I encountered is having multiple environments for your dev cycle than just two. For example, we push our solutions to a pre-production box in order to conduct UAT at the end of our sprints. If passed, we push again to production which would, as far as I can tell, require multiple environment variables to account for a Power Apps Portal subdomain change that we have to do between the three boxes. If you find a way to accomplish that without having to update your Flows with the multiple variables (which kinda defeats the point?), please let me know!
Keep in mind that there are limitations and several examples of when Environment variables should not be used:
- Moving passwords, secrets or other pieces of sensititve, protected data
- When multiple values are required to complete a definition (see example about about URL subdomains)
- When relationships need to be formed between configuration entities and entities for record data. Environment variables should be used for key-value pairs. New relationships cannot be created
In conclusion, Environment Variables can be of huge time saving importance if you can plan for them up front. While there’s no shame in a good Automate sob, we can save those tears for more important things…like a good Apps sob! 🙂
Leave a comment if you have had success using them and/or if you wanna add/correct anything I may have mentioned above.