Managing RPA Run Mode using Environment Variables
    • Dark
      Light
    • PDF

    Managing RPA Run Mode using Environment Variables

    • Dark
      Light
    • PDF

    Article Summary

    A common pattern used in Power Automate RPA implementations is using a development (or non-production) environment to build and unit test your solution prior to deploying to a production environment. In these development scenarios, often you will execute your RPA processes in attended mode whereas in production you will run in unattended mode.

    You can specify the Run Mode that you want to use through the dropdown that exists as part of the Power Automate Desktop action. But, part of the challenge with this approach is your Run Mode is embedded in your cloud flow configuration and poses challenges when you deploy to production and don’t want to modify the cloud flow configuration once it is in production.
    1-DesktopAction

    However, we can use Environment Variables to externalize this configuration and then just refer to our environment variable in our configuration so that we don’t need to modify our cloud flow in production. When our cloud flow runs, it will retrieve this Environment variable and inject that value into the runtime when it is needed.

    Note: To use this approach, you do need to have at least 1 Unattended flow added to your capacity for any environment where the Environment variable will be referenced – even if you are using attended mode. There is a save-time validation that will validate if the term “attended” is being used in your configuration, else it expects to have this license assignment in place for the current environment.
    2-Error

    Solution

    We will talk about 2 solutions as part of this blog. The first solution will contain our Environment variable. It is best to have this artifact isolated from our actual bots to provide more freedom from a deployment perspective.

    We can create a solution, in my case I called mine RPA Run Mode. From there I added a new Environment variable from the New dropdown. I subsequently configured this Environment variable to include a Default Value of unattended and a Current Value of attended. The Current Value will always be used when the Environment variable is used in a flow if it exists. If it doesn’t exist, we will then use the Default Value.
    3-RunMode

    When we configure our Cloud flow that calls our Desktop flow, we will use the Environment variable that we just created instead of explicitly choosing a value from the Run Mode dropdown.
    4-CloudFlow

    Testing

    When we run our Cloud flow, we will see in our logs that it ran in Attended mode.
    5-attended

    Now, if we delete the Current Value from our Environment variable and run our flow again, it will use Unattended mode.
    6-unattended

    Deployment

    To transport our Environment variable to a Production environment, we would want to ensure that our Current Value is removed from our solution package before we export it. That way when we do import it as a managed solution, our Unattended value will be set and any Cloud flow that references it will retrieve this value during execution.

    Conclusion

    In this post we discussed how we can externalize our Run Mode configuration using Environment variables. To see this content in video format, please check out this YouTube video.


    Was this article helpful?