Feature Toggles allow new components and changes to be deployed in an inactive state and enabled at a time when stakeholders or technical dependencies are ready.
This pattern can decouple the risk and logistics of the deployment itself from the business considerations involved in adopting a new feature, and helps to support the practice of small and frequent deployments.
Use a Custom Metadata Type to define one or more feature activation flags (i.e. one for the release or one per feature, depending on granularity needed). This can then be referenced in the following to dynamically activate configuration:
- Formula fields (e.g. AND($CustomMetadata.FeatureActivation__mdt.MyFeature.IsActive__c, [my_condition])
- Workflow, Process Builders and Visual Workflows (branching condition that checks the met value as shown above)
- Use a Trigger Framework which allows for deactivation of any given trigger handler via a Custom Metadata Type or Custom Permission. Apex Trigger Actions and Nebula Triggers are examples of open source frameworks which provide this capability
- Apex REST services should return an appropriate error if code is not active (e.g. “Service Inactive”)
- Use App assignment to allocate pages to a given App then only allocate that app to a Permission Set that is assigned when your feature is active
- Use a Custom Permission to set visibility on components added to a shared flexipage, add the custom permission to the permission set mentioned above
- For Page Layouts, create a new Layout for your feature, activation/deactivation will be managed by profile assignment
- The Feature Flag Designs open source framework provides rich capabilities for dynamically switching features using custom permissions and apex dependency inversion
These will be left active unless there are clear impacts from this approach (this assumes features that are inactive are not fundamentally changing the security or sharing model of core objects such as Account or Case in a way that impacts existing user groups).
Use a sharing framework that is metadata driven and caters for dormancy. The open source apex sharing framework FormulaShare operates through metadata-driven rules which can be deployed in a disabled state until required
- Whilst technical patterns above can be helpful, it's worth considering the first and simplest way to "toggle" a feature is to avoid deploying it until it's needed - if this is possible within other confines of your deployment process then this option should be considered first.
- When feature toggles are deployed, CI/CD pipelines and automated testing will need to setup to adjust to this, as code will be deployed dormant to some environments but active to others, this also means maintaining a separate ‘active’ or ‘dormant’ set of artifacts to enable this. Alternatively features are manually enabled/disabled.
- Cleanup effort is required post activation - for example we will want to remove references to feature toggles in validation rules and workflows once live as if we do not these statements will continue to proliferate throughout the environment