Feature flags or switches in Power Platform

In the past few weeks I dedicated time deep diving into DevOps and software development topics. During my reads, I was interested on the concept of feature flags/switches and the Power Platform development.

Feature flags helps developers address some development and deployment problems (check this article for details) but my interest was on those two:

• Test in production: Use feature flags to grant early access to new functionality in production. For example, you can limit access to team members or to internal beta testers. These users will experience the full-fidelity production experience instead of a simulated or partial experience in a test environment.
• Instant kill switch: Feature flags provide an inherent safety net for releasing new functionality. You can turn application features on and off without redeploying any code. If necessary, you can quickly disable a feature without rebuilding and redeploying your application.

Power Platform solutions developed by partners normally include some sort of application lifecycle management with separate Dev, Test, Prod environments that ensures best practices and solid testing before deploying solutions into production.

On other hand, citizen developers may have apps running directly in production (and that is ok if risks are identified!) and feature flags may be a solution to consider when deploying new versions of apps.

Let’s say that CorpTNN has a fully stable, running smoothly investment app for the past 18 months. It is now time to make some changes to the business critical process and UI but you only have a production environment.

Instead of refactoring the entire process on top of the existing one, the recommendation is to design the new investment process and UI on separate screens, fields, tables, cloud flows, etc. and add a flag on the code that controls which version will be available for end users.

On the Welcome screen, use a flag to decide which screen to open (bespoke or version2.0).

If(EV_Version = "yes",Navigate(scrInvestments_v20), Navigate(scrInvestments))

Environment variables or Setting definitions

There’s many other ways to implement the flags but let’s look at two of the main contenders under Power Platform features:

• Setting definitions – in theory settings should be the main option but limitations accessing those under canvas apps makes it hard to consider as an option
• Environment variables – although the use of environment variables is optimized for environment related values, it may be the best option to implement feature flags

There’s a great article from Benedikt Bergmann on the subject that I strongly recommend you to read. Although the article is from 2021, his findings are still up to date regarding the pros and cons of setting definitions and environment variables.

Setting definitions

The creation of custom setting definitions is quite handy and allows 3 levels of values: default, environment and app specific (model-driven app, not canvas app). This covers most of the scenarios where setting definition can be used as a feature flag. But then the complexity starts:

• Currently isn’t possible to access custom setting definitions from the Settings menu of model driven apps, which makes less intuitive to update the definition value.

• Default, Environment and App specific values are stored in separate tables of Dataverse.
• From a development perspective, accessing the setting definitions tables and values from the canvas apps editor isn’t possible directly, you are able to but need to use cloud flows to get the values (and logic is needed to find default or environment or app value).
• Although possible, all this level of complexity makes it really difficult to consider setting definitions as a flag.

Environment variables

From environment variables perspective, it is possible to access them in canvas apps. Not as simple as accessing environment variables from a cloud flow, but adding the following tables to the canvas app, is possible to get the environment variable value.

//Set EV_Version formula
EV_Version =  LookUp(
    'Environment Variable Values',
    'Environment Variable Definition'.'Schema Name' = "ff_EV_version20",
    Value
);

Conclusion

Although feature flags is a great development concept that citizen developers should take advantage when preparing new developments, using some of the standard features of Power Platform is not as simple as it should be. Many times, partners and citizen developers decide to build their own table to support settings!

Between the two options tested, I still recommend the use of environment variables for this purpose at least while Microsoft does not deliver enhancements on the setting definitions side.

I also wanted to test how quickly the changes to a environment variable or setting definition would be available in runtime. Official documentation mention that updates to values is an asynchronous process and may take some time to update. During my testing, both environment variable and setting definition changes were instant, which makes them perfect for kill switch scenarios.

And, this may seem logic but worth mention anyway, no republish is needed to new values take effect.