Prerequisite Flags

A prerequisite flag is a dependency between two flags: a child flag stays off until a parent flag serves a specific variation. The dependency is enforced inside the evaluator, before any of the child’s targeting rules run, so the gating logic lives in Featureflip rather than in your application code.

This replaces the if (parent) { check child } pattern that flag-heavy codebases tend to accumulate. Instead of duplicating a parent’s targeting across every flag that should follow it, each dependent flag declares the parent and the variation it requires, and the platform keeps them in sync.

How prerequisites are evaluated

Each flag carries an ordered list of prerequisites alongside its targeting rules and fallthrough. When the child flag is evaluated:

1. The evaluator walks the prerequisites in order.
2. For each one, it evaluates the parent flag against the same user context and compares the served variation to the variation the prerequisite requires.
3. If any prerequisite’s parent does not serve the required variation, the child short-circuits to its off variation and stops — the targeting rules never run.
4. Only when every prerequisite passes does the evaluator continue to the child’s targeting rules and fallthrough.

Because the check happens before targeting, a prerequisite is an AND gate across all of a flag’s dependencies: every parent must serve its required variation for the child to be considered “on” at all.

The same algorithm runs server-side in the Evaluation API and locally in each server-side SDK, so a flag check returns the same answer wherever it runs. For the exact reason strings the HTTP endpoint returns, see the Evaluate endpoint reference.

Variation match, not just on/off

A prerequisite names a specific variation the parent must serve, not merely “the parent is on.” That makes prerequisites work for multivariate flags. A plan-tier flag with variations free, pro, and enterprise can act as the parent for several entitlement flags, where one entitlement requires enterprise and another requires pro. When a customer’s plan changes and the parent starts serving a different variation, every entitlement that required the old value falls back to off in the same evaluation.

Featureflip prerequisites support equals matching only. To express “parent must not serve variation X,” invert the requirement by naming the variation the parent should serve instead.

What you see when a prerequisite gates a flag off

When a prerequisite is not met, the dependent flag serves its off variation with:

• reason set to prerequisite-failed (the server and HTTP Evaluation API) or PrerequisiteFailed (client-side SDK evaluation).
• prerequisiteKey set to the key of the first parent flag that failed its check.

That prerequisiteKey is what makes a misfiring gate debuggable from a single evaluation detail: the result names the parent responsible, rather than leaving you to inspect a child whose own rules all evaluated cleanly.

const detail = client.variationDetail('beta-checkout', context, false);

if (detail.reason === 'PrerequisiteFailed') {
  console.log(`beta-checkout gated off by ${detail.prerequisiteKey}`);
}

Guardrails

A few invariants are enforced for you, so a prerequisite graph cannot get into a broken state:

Guardrail	Behavior
Cycle detection	A prerequisite that would create a loop (for example flag-a depends on flag-b which depends back on flag-a) is rejected when you save it, with the offending chain returned in the error.
Depth cap	Prerequisite chains are capped at a depth of 10 as a defense-in-depth safety net. Realistic graphs are usually one to three levels deep.
Delete protection	You cannot delete a flag that other flags use as a prerequisite. The API returns 400 FLAG_HAS_DEPENDENTS with the dependent flag keys so you know what to unwire first.
Variation-removal protection	You cannot remove a variation that another flag’s prerequisite expects (VARIATION_HAS_DEPENDENTS).
Archive / restore	A flag cannot be archived while active flags depend on it, and a flag cannot be restored while its own prerequisites are still archived. Archiving an entire dependency chain in one bulk selection works.

Prerequisites vs. targeting rules

These solve different problems and run at different stages:

• A targeting rule decides which variation to serve, based on context attributes such as country, plan, or user ID.
• A prerequisite decides whether the flag may serve anything other than off, based on another flag’s result.

Prerequisites are checked first. If any prerequisite fails, the targeting rules never get a chance to fire.

Next steps

• How to Set Prerequisite Flags — add and manage prerequisites in the dashboard
• What Are Feature Flags? — flag types, variations, and the flag lifecycle
• Targeting & Segments — control which users see which variation
• Evaluate Endpoint — the reason strings and prerequisiteKey returned by the API

Frequently Asked Questions

What is a prerequisite flag?

A prerequisite flag is a dependency between two flags: a child flag stays off until a parent flag serves a specific variation. Featureflip enforces the dependency inside the evaluator, before the child’s targeting rules run, so the gating logic lives in the platform instead of your application code. Prerequisites are variation-match, so they work for multivariate flags such as a plan-tier flag, not only on/off booleans.

What is the difference between a prerequisite and a targeting rule?

A targeting rule decides which variation to serve based on context attributes such as country, plan, or user ID. A prerequisite decides whether the flag is allowed to serve anything other than its off variation, based on another flag’s result. Prerequisites are checked first; if any prerequisite fails, the targeting rules never run and the child serves its off variation.

What happens to a dependent flag when its prerequisite is not met?

The dependent flag serves its off variation, and the evaluation reason is set to prerequisite-failed (PrerequisiteFailed in client-side SDK evaluation). The result’s prerequisiteKey field names the parent flag that gated it off, so you can see exactly which dependency failed. Disabling a parent flag, or changing its targeting so it no longer serves the required variation, gates every dependent flag off in the same evaluation cycle.

Can prerequisite flags create circular dependencies?

No. Cycles are detected when you save a prerequisite and rejected, with the offending chain returned in the error. As a defense-in-depth safety net the evaluator also caps prerequisite chains at a depth of 10, but in practice most flag graphs are only one to three levels deep. You also cannot delete a flag, or remove a variation, that another flag depends on until the dependent references are removed first.