Salesforce feature flags let teams deploy finished code to production while keeping it switched off until business is ready. Instead of holding a release back in a branch for three sprints, you ship it dark, then flip a Custom Metadata record when the feature needs to go live. This turns release timing into a business decision rather than a deployment risk.
Most orgs never build this discipline. They rely on release freezes, branch gymnastics, and a prayer that UAT finishes before the next sprint's merge conflicts start. Feature flags fix the underlying problem: code readiness and business readiness are two different clocks, and most Salesforce pipelines pretend they're the same one.
What feature flags actually solve in Salesforce release cycles
Picture a Service Cloud team building a new case escalation workflow. Development finishes on schedule. Legal wants two more weeks to review the customer-facing wording. Under a normal branching model, that workflow either ships half-built or gets held out of the release entirely, dragging along every other change bundled in the same deployment.
A feature flag separates those two problems. The Apex, flows, and Lightning components deploy on schedule, wrapped in a check against a Custom Metadata record. The release goes out clean. Legal reviews on their own timeline. When they sign off, an admin flips one record and the feature goes live with zero additional deployment.
This matters more once release cadence increases. Teams running weekly or bi-weekly deployments cannot afford to hold an entire release hostage to one lagging approval. I have seen a single blocked feature delay four unrelated bug fixes because everything sat in the same change set. Flags decouple those decisions.
The native toggle options and where each one runs out of road
Salesforce gives you three realistic building blocks for flags, and none of them was designed for this purpose. That's fine. Plenty of good engineering patterns get built from parts meant for something else.
| Mechanism | Good for | Where it breaks down |
|---|---|---|
| Custom Permissions | Gating access by profile or permission set | Static assignment, painful to toggle per-record or per-cohort |
| Custom Metadata Types | Org-wide on/off switches, environment-specific config | No built-in audience targeting without extra logic |
| Custom Settings | Simple boolean flags, quick to build | Hierarchy model gets messy past a handful of flags |
Custom Metadata Types win for most teams because they deploy like code, version like code, and survive a sandbox refresh without extra setup. Custom Settings feel simpler at first but become unmanageable once you have fifteen flags across three clouds and nobody remembers which ones are stale.
Building a flag framework with Custom Metadata Types
Start with a single object: Feature_Flag__mdt. Give it a developer name, an active checkbox, and a rollout percentage field if you want gradual exposure. Apex classes, flows, and even Lightning components can query this object directly or through a thin utility class that caches the result.
The utility class matters more than people expect. Without it, developers scatter direct metadata queries across a dozen classes, and cleaning up a flag later means hunting down every reference by hand. One static method, one governor-limit-friendly cache, one place to retire the flag when the feature becomes permanent.
Naming convention is not busywork here. A flag called Case_Escalation_V2 tells you nothing six months from now when three more escalation projects have shipped. Prefix with the epic or project code, date-stamp the creation, and log an owner in a description field. Nobody remembers context after two sprints; the metadata has to remember it for them.
Feature flags vs sandboxes: why flags reduce environment sprawl
Some teams try to solve the same problem by spinning up a dedicated sandbox per feature branch, then merging everything back before release. It works, technically. It also multiplies your data masking, seeding, and refresh overhead across every parallel branch, which is exactly the kind of sprawl a DevOps-focused org should be trying to shrink, not grow.
Flags let one integration sandbox and one UAT environment cover far more ground. Instead of maintaining five feature sandboxes with slightly different metadata states, you maintain one environment where five flags sit in different positions. Less environment drift, less time spent reconciling which sandbox has which half-finished feature.
This is also where tools like DeployEzee earn their keep. A deployment pipeline that understands flag state as part of the release package, not an afterthought, means the same release notes that document metadata changes also document which flags flipped and why. Skip that tracking and you end up with a production org full of mystery toggles nobody can explain during an audit.
Governance: who actually owns the kill switch
Flags without ownership rules turn into technical debt fast. Somebody builds a flag for a Q3 campaign, the campaign ships, and the flag sits there in an active state through Q4, Q1, and eventually a security review flags it as an undocumented access path. That review is not wrong to be nervous about it.
Assign an owner to every flag at creation, not after the fact. Set a review date in the metadata record itself, ninety days out by default, and build a simple report that surfaces stale flags nobody has touched. Release management should treat flag cleanup the same way it treats validation rule cleanup: a recurring task, not a one-time favor.
Decide early who has permission to flip a flag in production. Developers should not be toggling live features from a debug console because a demo is running late. That decision belongs to release managers or product owners, tracked through a change request, same as any other production change.
Rolling flags into CI/CD without slowing releases down
The whole point of a flag strategy collapses if flipping a flag still requires a full deployment cycle. Custom Metadata records should be editable directly in production by an authorized admin, through a lightweight Lightning page or even a well-permissioned list view. That is the entire mechanism. No change set, no pipeline run, no waiting for the next release window.
Your CI/CD pipeline still needs to own the initial deployment of the flag definition and the code that checks it. That part goes through the same validated, tested path as everything else. What changes is the activation step happening independently, on business timing rather than deployment timing.
Track flag state changes in whatever tool logs your deployments so a rollback plan has full context. If a feature causes problems after going live, the fastest fix is often flipping the flag back off, not rolling back a deployment. That's a five-second fix instead of a rollback conversation with three stakeholders on a call.
Frequently Asked Questions
What is a feature flag in Salesforce?
A feature flag is a toggle, usually stored in a Custom Metadata Type record, that controls whether a piece of deployed functionality is active. The code ships to production as normal, but a check against the flag determines whether users actually see or use it. This lets teams separate the deployment date from the go-live date.
Should I use Custom Settings or Custom Metadata Types for flags?
Custom Metadata Types are the better choice for most feature flag frameworks because they deploy through standard metadata tools and survive sandbox refreshes cleanly. Custom Settings work for a handful of simple boolean toggles but get harder to manage once an org accumulates more than a few flags. Most teams that start with Custom Settings end up migrating to Custom Metadata Types within a year.
Do feature flags replace the need for multiple sandboxes?
Flags reduce the number of feature-specific sandboxes a team needs, since one shared environment can hold several flagged features at different stages of readiness. They do not remove the need for a dedicated integration or UAT sandbox entirely. The reduction is in sprawl, not in your overall sandbox strategy.
Who should have permission to toggle a production feature flag?
Flag toggling in production should sit with release managers or product owners, not individual developers, and should route through a change request like any other production change. Giving developers direct toggle access tends to lead to ad hoc flips during demos or incident response that never get logged. A simple permission set restriction on the metadata object solves most of this.
How do feature flags help with Salesforce rollback plans?
When a newly released feature causes an issue, flipping its flag back off is usually faster and safer than rolling back an entire deployment. This gives release teams an immediate mitigation step while they investigate root cause, rather than forcing a full rollback conversation. It works best when flag state changes are logged alongside deployment records so the team has full context during an incident.