Using Environment Variables to Make Your Flow Configuration Portable
    • Dark
      Light
    • PDF

    Using Environment Variables to Make Your Flow Configuration Portable

    • Dark
      Light
    • PDF

    Article Summary

    Ideally, when we deploy a flow from one environment to another, we shouldn’t have to modify it to ensure we don’t accidentally introduce a bug as we deploy our solution. One way that we achieve this is through the use of Environment Variables.

    For example, we may have a scenario where we need to assign an approver, or list of approvers, as part of an approval process. In our Dev environment, we may want to use our email address while we test so that we don’t disrupt the business users while our development is in progress. However, once we deploy our flow to production, we want to use a business user’s email address instead. But we want to be able to perform this configuration, without modifying our flow.

    In the following steps we will build out our solution that incorporates Environment Variables.

    • Let us start by creating a solution as that is a pre-requisite to using the Environment Variables feature. From the Power Automate Maker portal, click on Solutions – New solution and then provide the necessary inputs.

    1-NewSolution

    • Now, create our Environment Variable and we can do so when we are inside of our solution and then click on New – Environment variable.

    2-EnvironmentVariable

    • We now need to provide our Environment Variable details. The two important values to focus on are the Default Value and Current Value. You can think of the Default Value as your target value that you want to use in your Production environment and the Default Value as your overriden value that you will use in your Dev environment. When there is no Current Value, the Default Value will be used.

    3-envValue

    • We can now add a flow to our solution by clicking on New – Flow.

    4-NewFlow

    • Within our flow, let’s start by adding a Manually trigger a flow trigger, initializing a variable called approvalEmail and then making a List records call to CDS that targets the Environment Variable Definitions entity and provides a Filter Query of schemaname eq 'creb5_ApprovalEmail'.

    Note: creb5_ApprovalEmail is the name of the Environment Variable that we previously created. Mileage may vary based upon what you named your variable.
    5-flowPart1

    • For the next part of our flow, we will add a Set variable action where we will set the Default Value to this variable. But, if we have a Current Value set, it will not be available as part of our the Environment Variable Definitions entity. Instead, we need to make a subsequent call to the Environment Variable Values entity and pass in _environmentvariabledefinitionid_value eq Environment Variable Definition as part of our Filter Query.
    • If a Current Value has been set, we will be able to loop over that result set and can override our approvalEmail variable with our Current Value. If there are no records returned, we will not override our variable and our Default Value will be used.
      6-flowPart2

    Testing

    Let’s go ahead and run our flow, where we have a Current Value set as an Environment Variable. Here we can see that our Current Value has been successfully retrieved.
    7-test

    Now, lets go remove our Current Value and observe the behavior. Since we will keep our flow in the same environment, we will select Delete from this environment. If we were going to move this flow to another environment, then Remove from this solution would have been more appropriate.
    8-delete

    When we run our flow again, we will determine that the Current Value doesn’t exist and as a result we will leverage the Default Value instead.
    9-test2

    Conclusion

    In this post we discussed how we can use configuration stored in CDS to make our flow configurations portable across environments without the need to modify them in other environments.


    Was this article helpful?