3 key use-cases for implementing environment variables in ALM

Environment variables play a pivotal role in advancing your Application Lifecycle Management (ALM) in the Power Platform. They offer a centralized and dynamic solution to store and manage configuration settings, credentials, and sensitive data. Leveraging environment variables allows for seamless customization and maintenance of your Power Platform solutions across various environments.

To access an environment variable within a Power App, you can utilize the following Power FX code, replacing “tv_Environment” with the Schema Name of your variable:

LookUp(
    'Environment Variable Values',
    'Environment Variable Definition'.'Schema Name' = "tv_Environment",
    Value
)

To optimize performance, it is recommended to perform the lookup once and store the value in a variable within the App.OnStart code:

Set(
    gblTextEnvironmentType,
    LookUp(
        'Environment Variable Values',
        'Environment Variable Definition'.'Schema Name' = "tv_Environment",
        Value
    )
)

Now, let’s delve into three common use-cases for implementing environment variables:

1. Environment Type

In most solutions and projects, I’ll create an environment variable called “Environment Type”. This variable typically expects a text string representing the Power Platform environment type, such as “DEV”, “UAT” or “PROD”. The solution uses it as a guide to determine how to treat the current environment.

For Power Apps, you can leverage this variable to control the visibility of certain controls based on the environment type. For instance, you can use the visible property of a control to check if it matches any of the environment types:

gblTextEnvironmentType in ["DEV", "SIT"]

By using the example above, you can conveniently debug and test specific functionality in DEV and SIT environments. Managed solutions restrict direct editing, making this super handy.

Additionally, you can employ more advanced logic using environment variables in conjunction with the switch function in the App.OnStart code. This allows you to define AD Groups for Role-Based Access Control (RBAC) based on the environment. The example demonstrates how you can select specific tables of roles and Azure AD Group IDs based on the environment type and subsequently check if the user belongs to each AD group using the Office365Groups Connector.

ClearCollect(
    colUserADGroups,
    AddColumns(
        Switch(
            gblTextEnvironmentType,
            "DEV",
            Table(
                {
                    Role: "Basic User",
                    ADGroup: "786e9c42-13f7-4a4d-96a6-06b6e32f1d28"
                },
                { 
                    Role: "Admin",
                    ADGroup: "e4bd7c2f-9a7d-40f9-a0f2-50b45974c502"
                }
            ),
            "UAT",
            Table(
                {
                    Role: "Basic User",
                    ADGroup: "d68c7a2e-742a-4b7f-8b25-8d80e27e9dfe"
                },
                { 
                    Role: "Admin",
                    ADGroup: "520ab24c-f1d3-4174-a63d-2dc6f7422f8e"
                }
            ),
            "PROD",
            Table(
                {
                    Role: "Basic User",
                    ADGroup: "a1c9426f-1e57-45c7-88d8-423285883c5b"
                },
                { 
                    Role: "Admin",
                    ADGroup: "c9a7e853-6c56-4b6d-8b73-ee8f26a8a607"
                }
            )
        ),
        "Member",
        IfError(
            User().Email in Office365Groups.ListGroupMembers(
                ThisRecord.ADGroup,
                {'$top': 999}
                ).value.userPrincipalName,
            false
        )
    )
);

Role	ADGroup	Member
Basic User	786e9c42-13f7-4a4d-96a6-06b6e32f1d28	true
Admin	e4bd7c2f-9a7d-40f9-a0f2-50b45974c502	false

Different lookups can performed on this collection across the app to check if users have permissions to perform certain actions. By utilizing this technique, you can seamlessly manage security and access across different environments within your Power App.

2. SQL Server (Power Automate Only)

As your solution traverses different environments, it is often necessary to utilize different SQL servers to adhere to ALM best practices and maintain separation. While dynamically changing the SQL server name in Power Apps can be challenging, it can be easily achieved in Power Automate.

By creating a text-type environment variable in your solution and setting it to the desired SQL Server Name, such as “myDEVdbserver.example.com,” you can dynamically specify the database to be used based on the environment when creating Power Automate Flows with the SQL connector. This ensures that your flows consistently connect to the appropriate database as your solution moves between environments.

3. Azure Connectors

The Power Platform offers various connectors for Microsoft Azure services, including Azure Data Factory and Azure VM. These connectors often require specific parameters unique to each environment, such as a Subscription ID (GUID) and Resource Group (Name). Environment variables can be conveniently used to store and retrieve these parameters. This ensures that your Power Platform solutions interact with the relevant subscriptions and resource groups in Azure.

By leveraging environment variables, you can seamlessly align your solutions with the appropriate Azure subscriptions and resource groups, facilitating efficient integration and interaction with Azure services.

Conclusion

By incorporating environment variables into your ALM strategy, you can enhance flexibility, security, and scalability while effectively managing your Power Platform solutions across diverse environments.

If you want to learn more about Environment Variables and how to automatically set them in solution deployments, check out deployment settings files for Azure DevOps Pipelines.