Skip to main content

​
Feature flag operations

Feature flags let Starfire ship and test capabilities without exposing every change to every account at once.

​
Flag vs entitlement vs permission

These are different layers:
  • Feature flag — is the capability rolled out to this context?
  • Entitlement — does the plan include the capability?
  • Permission — may this user/resource perform the action?
A missing feature can be caused by any of the three.

​
Common targeting dimensions

Depending on the current flag system, rollout can consider:
  • environment
  • plan
  • organization
  • user/account
  • internal/experimental cohort
  • percentage or named rollout group

​
Change a flag safely

  1. Identify the exact feature and current default.
  2. Identify the target population.
  3. Confirm dependent backend/UI components are deployed.
  4. Start with the smallest useful cohort.
  5. Verify behavior and health.
  6. Expand gradually.
  7. Remove temporary overrides when the rollout becomes the default.

​
User overrides

A user-specific override is useful for support/testing, but it can make behavior differ from the plan/organization default. Record why it exists.

​
Disable during incident

A feature flag can sometimes provide fast mitigation when one capability is failing. Disabling a feature is not a substitute for incident tracking and root-cause work.

​
Avoid permanent flag debt

Retire old rollout flags after the feature becomes stable. Long-lived forgotten flags make support and access reasoning harder.
Never use a feature flag to bypass a security permission. Flags control rollout, not authorization.

Feature availability model

See how flags combine with plan, policy, permissions, and provider health.