Tenant-specific feature flags let a SaaS provider pilot a capability, support plan entitlements, or roll back a risky path without separate deployments. Flag evaluation must be deterministic, tenant-scoped, observable, and independent of client-provided values.
Last updated: September 26, 2026.
CREATE TABLE tenant_feature_flags (
tenant_id BIGINT NOT NULL,
feature_key VARCHAR(100) NOT NULL,
enabled BOOLEAN NOT NULL,
updated_at TIMESTAMP NOT NULL,
updated_by BIGINT NOT NULL,
PRIMARY KEY (tenant_id, feature_key)
);Store stable feature keys in code and explicit tenant overrides in data. A missing override falls back to the environment’s documented default.
Evaluate on the server
Resolve the authenticated tenant, read the flag through one feature service, and return the decision to downstream code. Hiding a button in the browser is not authorization. If the feature exposes new data or actions, enforce the same roles and permissions on the server.
Cache and refresh safely
Cache each tenant’s configuration separately and choose a maximum staleness that matches rollback requirements. A sentinel or version value can invalidate all flags for one tenant without flushing global state. Microsoft’s multitenant configuration guidance recommends tenant-prefixed keys and separate tenant cache entries.
Manage the flag lifecycle
- Document owner, default, purpose, and expiry date.
- Roll out to internal tenants, then a measured cohort.
- Monitor errors and business outcomes by evaluated variation.
- Record administrative changes in the audit log.
- Remove the flag and dead branch after rollout or cancellation.
Schema-dependent features need backward-compatible multi-tenant migrations before activation. Avoid using temporary rollout flags as permanent billing logic; plan entitlements need their own durable model.
