I am current engaged in a project where a vendor suggested to the customer to use the same entity for various purposes. That decision might have worked for some organizations, but it did not have a foresight of the future requirements of the organization.
Moving forward a couple of years, we finally have the bandwidth to go ahead and split this into a couple of entities. The only issue with this is that the amount of work is substantial, and at the same time we need to continue developing other processes and deploying enhancements and bug fixes across our higher environments.
In the past, while working on custom software projects, we recently had the need to use Feature Toggles (also referred to as Feature Flags). Feature Flags are used in many places for preview features, experimental toggles, A/B testing, permissions toggles and other toggles that you might encounter.
Feature Flags allows the developer team to modify system behavior without changing code. The solution would reach the code that it needs to execute, and based on the Toggle, would select to go via route A or route B. An example of this would be a process that sends an Invoice to and end user. The company address is changing, and we have two versions of this invoice. We add a feature toggle that specifies whether to use the new address or the old address. When the company moves, all that has to be done is change the toggle, and from that point on, only the new Invoices will be printed.
In order to implement this in our Power App, we first need to create a couple of entities to store the data, or the features. The first entity will be called the Feature Flag, and the second entity is an optional entity which will be called Feature Access.
The Feature Flag entity will basically contain a name for the feature, and a two options field to determine whether the feature is active or not (basically use Option 1 or 2). We can also just use the Status of Active or Inactive.
In our case, we sometimes want features to be available to a subset of users (for testing purposes or partial access). The Feature Access entity has a relationship between the Feature Flag and a User or Team (Owner).
When the Feature Flag is enabled for partial access based on the Feature Access entity, the application will check whether or not a user or a user that is a member of a team have access to a particular feature. If they do, it will show the new version of the feature, if they don’t it will show the previous version of the default option.
In order to implement this, we had to add logic code for our Plugins and our Scripts. We also added a Custom Workflow Activity that would help us control the flow within our workflows. The same, of course could be done with Power Automate flows if required.
Let’s take a look at the custom code. Our plugin code, simply reads the combined data between both entities using a fetchXml statement and returns a value of true or false determining if the user has access to the new feature.
The javascript code does the same and also calls the Xrm.WebApi and uses a fetchXml statement to retrieve a boolean value.
Source code for this post is available on Github. Make sure that the variable names in the code match the entity names.