Environment Variables – Part 2

So, turns out I’m glad I decided to do this topic as my foray back into tech blogging cause it reminded me to always finish the article before assuming I understand the concept.

(This admission of guilt was brought to you by our new sponsor! Crow – Eating it will make you humble!)

My assumption was that environment variables would function similarly to other dynamic content that was available to both connectors/actions alike. However, that’s not the case and I owe you, fellow readers, a follow up to the previous post that explains the where my assumption was incorrect.

(This is where anyone else who finished the entire article and actually read the example can post a comment that simply says “CAW CAW CAWWWW!!!”)

Essentially, instead of a piece of dynamic content that can be inserted into a Flow as an action/trigger, Microsoft has created another configuration entity for us to add default values to. So what you’re seeing in the gif is what the article says needs to be in place for the environment varible to function as intended.

Phew. That’s a mouthful.

In other words, if my understanding is correct, for the time being we’ll have to add that entire section to each Flow in which we want to use our environment variable(s) until they improve the feature which they mention will happen sometime in the future.

So, the practial use of Environment Variables comes down to this important question: are they really worth the initial set up or should I simply bite the bullet and make the changes each time I push a new build?

The answer, of course, depends. One of the current projects I’m involved with could definitely have used the initial effort of getting these right since we have many, many places to try and update our Portal subdomains each time we move a solution from one environment to the next. On the other hand? I doubt I’d take the time to set these up for every flow that could use them if the project only requires a few to be created. At least, for the time being until they update the feature like I mentioned previously.

Thoughts? What scenarios can you imagine yourself using them in? Would love to hear ’em for my own benefit as well as those who may have stumbled upon this thread.

Also, after following the steps outlined in the article from yesterday, I’ve encountered the following error that I’m not sure how to solve:

It’s saying there’s not a property called “environmentvariabledefinitionid” on the output but, if you can see in the gif, it’s literally right there…sooooo…looks like I’m gonna be digging into this for a bit and I’ll let you know the findings in part 3 tomorrow!

Cheers,

DC

Power Automate – Environment Variables

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:

New Environment Variable Set Up

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.

Happy Flowing!

Here Goes Nothin’

I’ve been challenged. And, as anyone who knows me understands, that challenge cannot go unanswered! 🙂

My friend and colleague Mohsin Khalid and I have decided to focus a more concerted effort in giving back to the community who has given us so much. So, it’s with very little fanfare that I announce this is where I will be blogging, posting original video tutorials and creating a weekly podcast, hosted by the two of us, in which we explore Microsoft’s Power Platform from both a functional (mine) and technical (Mohsin’s) perspective.

The challenge is to not let this lapse for a year at the least, do 2 posts a week, answer as many Power Platform Community questions as I can (links to the individual community websites below) and record the weekly podcast. It’s…a lot, to be sure. Not to mention that whole pesky full time job, quarantine, home schooling and the other various creative projects I have in myriad states of completeness. So, I’ll need all the encouragement I can get! Please comment, subscribe, follow, bookmark, etc. if you’re at all interested in this stuff cause I can promise you that you’ll find something interesting here…eventually…maybe…actually, nevermind. I can’t make that promise lol. HOWEVER, I’m sure gonna give it that good ‘ole college try.

Cheers!

(Photo Credit: Dick Clark – Neowise in my backyard)

DC

Community Websites:

Power Automate
Power BI
Power Virtual Agents
Power Apps