FeatureSignals

Prerequisites

Prerequisites let you chain feature flags together so one flag depends on another being enabled first. Think of it as a dependency graph for your feature flags — flag B only activates if flag A is already ON.

What Are Prerequisite Flags?

A prerequisite is a flag that must evaluate to enabled (return a non-default value) before the dependent flag can activate. If any prerequisite is not met, the dependent flag returns its default value — regardless of its own enabled state, targeting rules, or percentage rollout configuration.

A flag can have multiple prerequisites. Allprerequisites must be met for the flag to evaluate normally — it's an AND relationship, not OR.

When to Use Prerequisites

  • Infrastructure dependencies. A feature requires a new database migration or a third-party service that is gated behind its own ops toggle. The feature flag should depend on the infrastructure flag.
  • Feature hierarchies. A premium analytics dashboard ("analytics v2") depends on the base analytics feature being enabled. If base analytics is off, analytics v2 should not activate.
  • Platform migrations.You're moving from service A to service B. The new-service flag depends on the migration-complete ops flag. No one gets routed to the new service until the migration is confirmed.
  • Compliance gates. A feature that handles PII requires a data-retention feature to be enabled. The prerequisite enforces the dependency at runtime.

How It Works

Prerequisites are checked early in the evaluation order — after the flag existence check, environment enabled check, and mutual exclusion, but before targeting rules. This means the engine doesn't waste cycles evaluating complex targeting rules for a flag whose prerequisites aren't met.

text
1. Flag exists?                → No: NOT_FOUND
2. Flag environment enabled?    → No: DISABLED
3. Mutual exclusion group?      → Check group winner
4. Prerequisites met?           → No: PREREQUISITE_FAILED (return default)
                                   Yes: continue
5. Targeting rules match?       → Yes: TARGETED
6. Percentage rollout?          → In bucket: ROLLOUT / Out: FALLTHROUGH
7. None of the above            → FALLTHROUGH

Example: Infrastructure Dependency

Let's walk through a real scenario. Your team is introducing a new search backend powered by Elasticsearch. The rollout plan:

FlagTypeRole
elasticsearch-migration-doneOps toggleInfrastructure gate — flipped ON after the migration is verified
new-search-backendRelease toggleFeature flag for the new search experience

The new-search-backend flag has elasticsearch-migration-doneas a prerequisite. Here's what happens:

  1. Deploy the feature code. Both flags exist. elasticsearch-migration-done is OFF. new-search-backend is ON. Despite being ON, new-search-backend returns its default value (old search path) because its prerequisite is not met.
  2. Run the migration. Elasticsearch is populated and verified. The ops team flips elasticsearch-migration-done to ON.
  3. Feature activates. Now that the prerequisite is met, new-search-backend evaluates normally. If its targeting rules or rollout conditions match, users start seeing the new search experience.
  4. Clean up. After a few weeks, the old search path is removed. The elasticsearch-migration-doneflag is deprecated (it's permanently ON). The new-search-backend flag is removed from the codebase.

Configuring Prerequisites

Set prerequisites when creating or updating a flag. The prerequisites array contains flag keys that must be enabled first:

bash
curl -X PATCH https://api.featuresignals.com/v1/projects/$PROJECT_ID/flags/$FLAG_ID \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "prerequisites": ["elasticsearch-migration-done"]
  }'

Best Practices

  • Keep dependency chains short. Deep chains (A → B → C → D) are hard to reason about and debug. Prefer 1–2 levels of prerequisites.
  • Use ops toggles as infrastructure gates.Separate infrastructure concerns from feature concerns. An ops toggle communicating "the migration is done" is clearer than a release toggle pulling double duty.
  • Document the dependency. Add a description to the dependent flag explaining why it requires the prerequisite. This helps during cleanup.
  • Avoid circular dependencies.The API rejects circular prerequisite chains at write time, but it's good practice to plan your dependency graph before creating flags.
  • Clean up prerequisites when they're no longer needed. After the infrastructure migration is complete and the old code path is removed, update the dependent flag to remove the prerequisite.

Next Steps