nsr_keyto the schema name of your field and you’ll have to change the filter query to match the value of the key in your environment variable record. That’s it. Now you can use that variable you initialized anywhere in your flow. For us this is super useful in flows that send notifications to users either by email or Teams. In the screenshot above, the value being grabbed is the base URL for the model-driven app for our service team to handle cases and such. From there we feed it into an adaptive card that gets posted to a channel. This way we can easily link to the record in the card and persist the flow across both environments. Speaking of which, you can deploy flows with your solution which makes it really easy to develop flows, test in development, and then move to production. We’ll be covering that in some other post, but for now thanks for reading and I hope it helped!
We’ve started to use Power Automate flows coupled with Dynamics 365 in place of workflows. It seems to be the trend that Microsoft wants us to make, so who am I to argue. One of the issues I ran into was building Flows that could work in both our production and development environments. For instance, if you’re going to send a link to a record the URL will change depending on the environment selected. My solution to this is to use a custom entity that I’ve called Environment Variables. The schema is pretty easy. Create a new entity in your solution and add two custom fields: “Key” and “Value”. Accessing these in a flow is very simple: This is just a sample from a flow I’ve built. You’ll have to change