Skip to content

How to Set Prerequisite Flags

Prerequisites let you make one flag depend on another: a child flag stays off until a parent flag serves a specific variation. This guide walks through adding and managing prerequisites from the web dashboard. For the underlying model — evaluation order, variation matching, and guardrails — see Prerequisite Flags.

  1. Open a flag from the Flags page at /flags.
  2. On the flag detail page, select an environment tab (e.g., Development, Staging, Production).
  3. The Prerequisites section appears beneath the targeting rules.

Like targeting, prerequisites are configured per environment, so a flag can depend on a parent in production while running freely in development.

  1. In the Prerequisites section, click Add Prerequisite.
  2. Choose the parent flag from the first dropdown — the flag this one should depend on.
  3. Choose the required variation from the second dropdown — the variation the parent must serve for this flag to be considered on. The variation list re-populates when you change the parent, so it always reflects that parent’s current variations.
  4. Click Save.

You can add more than one prerequisite. They form an AND gate: every parent must serve its required variation before this flag’s targeting rules are evaluated. If any prerequisite is not met, the flag serves its off variation and no rules run.

What happens when a prerequisite is not met

Section titled “What happens when a prerequisite is not met”

When a parent does not serve the required variation, the dependent flag serves its off variation and the evaluation reason is set to prerequisite-failed (PrerequisiteFailed in client-side SDKs), with prerequisiteKey naming the parent that gated it off. You can confirm this without deploying:

  1. Click Evaluate on the flag detail page.
  2. Enter a JSON evaluation context.
  3. The result shows the served variation, the reason, and the prerequisite key when a prerequisite gated the flag off.

Open the flag, find the row in the Prerequisites section, and remove it. The flag is then evaluated on its targeting rules alone.

To stop being a parent for another flag, you remove the prerequisite from the child instead — a parent does not track its dependents, the dependency is declared on the child.

Two cases are surfaced inline in the editor rather than as opaque API errors:

  • Cycle rejected. If a prerequisite would create a loop (for example flag-a requires flag-b, which already requires flag-a), the form shows the offending chain and refuses to save.
  • Dependent blocks delete. If you try to delete a flag, or remove a variation, that another flag depends on, the response lists the dependent flag keys. Remove those prerequisites first, then retry.
  • Make the parent own the schedule. Put the rollout percentage or targeting on the parent and let dependents follow it, instead of duplicating the same targeting on each child.
  • Keep chains shallow. One parent with several direct dependents is easier to reason about than a long chain. If you are approaching the depth cap of 10, flatten the structure.
  • Name the dependency in the description. A short note on the child flag (“gated on new-checkout-v2 = on”) saves the next person a lookup.
  • Remove dependencies during cleanup. A flag cannot be archived or deleted while others depend on it — unwire prerequisites as part of removing a flag.