Feature flags

In a continuous delivery model, you’re often faced with a discrepancy between what you want to release from a business point of view and what you want to release technically. Code might be ready, but your users might not be. We’d want to continue to deploy our features in Production, without affecting business process and users. We do this by performing dark releases. We deploy the capabilities to production, but we don’t enable them.

In that case, we apply feature toggles or flags. These take different shapes depending on the use case.

Within Salesforce, the following options are available to us - without too much hassle - to feature flag capabilities:

• User specific attributes: a property on the user that indicates whether or not they have access to the feature. Scales poorly, because of the amount of intricate features you can have that need to be dark released.

• Custom Permissions: we can create custom permissions and assign these to users. Typically we’d create a permission set for the entire capability that includes other access to that feature. For example, an inventory capability can be deployed which has a set of metadata components such as objects, lightning web components, tabs, apex classes, etc. We’d setup a permission set that has all of this access, including the custom permission we’d create for “Inventory Management”. If we’d like, we can assign the permission set to individual users, or roll it up into a persona specific Permission Set Group. In both cases, these users will get access to the capability while people who aren’t assigned this permission set will not. This scales particularly well in a variety of use cases. The native API custom permissions offer in items such as Validation Rules, Apex etc. makes this approach our favorite. In Experience Sites or Lightning Record Pages, you can also play around with Visibility Criteria or Audiences that check for this custom permission. The user specific attribute approach also works with this.

• Metadata activation: sometimes, metadata can be activated or deactivated. If it’s not part of a larger process, or suite of metadata, this might work. An example of this is an Record Triggered flow we keep inactive rather than deploying it in an active state. This will only apply in a handful of scenario’s where we keep the metadata so specific and wouldn’t have a single dependency.

• Custom Metadata Type or Custom Settings: A set of data constructs that make up the feature activation specific to whatever you want. Both custom settings & custom metadata types offer a great deal of flexibility. This approach however, requires a scalable Apex service that can be called from all types of configuration (except validation rules) such as Flows, Lightning Web Components, etc. Usually we see a binding of related metadata / actual data being to the feature activation. This approach also offers additional customization capabilities that allow for example partial feature exploration or data specific enablement. If you for example have accounts that you want to enroll into the feature, rather than Users, this approach is useful.