My journey with Dataverse started as citizen developer. I discovered this funny new environment and used canvas apps for cool & portable demos. After a while, my demos, prototypes, and tiny apps became a productive status and started to grow.

I think each of us knows these problems and the resulting questions. I faced new challenges: How can I maintain my apps and how can I continue adding new features? Furthermore, how can I stop breaking existing features?

Well, the answer is simple: Isolated Development. Therefore, it’s time to act like a Pro-Developer and setup Application Lifecycle Management for my power apps!

Dataverse Environments

Let’s start with a short wrap up of Dataverse Environments. As a citizen developer you normally start in the Default Environment of your company. Every licenced user have the Environment Maker role and can create power apps. This is perfect to discover Dataverse. But on the other hand, you have limited control in this environment.

I prefer for development the Developer Environment. This give me the freedom to prepare new versions of my apps, try out new things without breaking and changing the shared (published) version. This is because, I’m the only user in my Developer Environment. The con, I can’t share my Power Apps here with other users for testing.

A Production Environment is in my opinion the right place to host my released PowerApps. I have full control in this environment. Furthermore, I can enforce my security concept as well as I can apply my data loss prevention (DLP) policies for my data connectors.

From perspective of Application Lifecycle Management I need also a test environment for my key users. There I can deploy a new release with new features and bug fixes of my power apps. This is because, my test users need access to the preview versions during my productive app isn’t touched. As Test Environment, I can choose between another Production Environment or a Sandbox Environment.

Note:
Previously, I could create only 2 productive environments with a PowerApps P2 license. Microsoft have changed this and now, Admins can govern environment creation … read more

My tip for you: Make your environments visible!

My biggest question during development, testing and productive usage is: How can I identify my power app in a specific environment? Therefore, I want to see my power app version and highlight my environment information.

In the following screenshot, you see my power app in my Developer Environment. Currently, My DEV version is currently an old version to evaluate some old functionality. As result, my power app versions is 2.3.8 in this environments:

The latest release of my power app is version 2.3.11. I deployed this version to my Test Environment. Furthermore, I shared my power app TEST version with key users. Therefore, everyone should know that this is my Test Environment & TEST version. This power app contains untested functionality and new features – it’s preview:

Finally my Production Environment don’t need to be highlighted. However, my PowerApp version must be visible. This helps during support. I can identify issues in a specific version and my users know, when a requested feature is rolled out.

Adding a Text Label and changing the value works fine for my power app version. But what about labeling my environment identification? So my question is: Where should I store my environment information? … I have found a solution…

Environment Variables

A very useful feature in Dataverse are Environment Variables. You can use it for configuration settings or input parameters. Therefore, environment variables are normally added to a solution. However, the data of these variables is stored in Dataverse tables in the specific environment:

Now, I need a fast way to setup my system indicator. I do this once per system.

First of all, I have added a new record “SYSTEM-ID“ to table “Environment Variable Definition”. In my example, my Developer Environment got as default value “DEV” … obviously for development:

After saving, I added a value in “Environment Variable Values“ for my created variable definition. I used also as value “DEV”:

Finally it was time to include the table “Environment Variable Values“ as data source into my power apps.

This was because, I want to show the current value in a label. In conclusion, I have used this code:

Text: =LookUp('Environment Variable Values', 'Environment Variable Definition'.'Display Name' = "SYSTEM-ID", Value)

I have also used the Visible property of my Label to avoid showing the “SYSTEM-ID” in my Production Environment:

Visible: =LookUp('Environment Variable Values', 'Environment Variable Definition'.'Display Name' = "SYSTEM-ID", Value) <> "PROD"

… Low-Code with great benefits…

Summary

Environments are important in Application Lifecycle Management. I usually use at least 3 of them. One is my private Development Environment. The second is the Test Environment for my key users to run user acceptance tests and ensure the functionality of my power apps. Finally, the last one is my Production Environment where I share my power apps to all users. In detail, each of my environments serves a specific purpose.

The next part of my basic environment setup is that I always want to see what environment I’m using. For this reason I have manually created an environment variable “SYSTEM-ID. I use different values for each environment: “DEV” for Development, “TEST” for Test, and “PROD” for Production. In addition, I would also like to see the version of my power app. To keep this simple, I manually change the power app version (Text Label) in my power app during development.

Now, I have a well prepared environment for Pro Developer “stuff” like Application Lifecycle Management. I can develop my power app isolated in DEV as a Citizen Developer. Afterwards, I can prepared and rollout my new version to UAT where it’s safe for testing. Finally if all my quality gates are passed – OK from test users -the new power app version is released to PROD for all users.