Skip to main content
This page covers the admin-side flow behind Overview and Getting started: how environments, flags, targeting rules, and rollouts attach to each other, and what to do when something needs fixing after the fact — a lost SDK key, a rule that isn’t matching, a rollout that needs to change.

​
How a value gets decided

Before the individual pieces, here’s the order they’re applied in when a flag is evaluated: Targeting rules are evaluated in ascending priority order (lowest number = highest priority); the first matching rule wins. If no rule matches, evaluation falls through to the percentage rollout (if configured), then to the flag’s base isEnabled value.

​
Environments

An environment groups runtime settings and produces exactly one SDK key, shown in full only at creation time — the same behavior covered in Getting started, Step 1.
If the SDK key is lost or exposed, rotating it invalidates the old one — see If an SDK key leaks below before you switch any traffic over.

​
Flags

Flag keys are the stable identifiers your application code depends on; names are just the human-readable label shown in the dashboard. Keep the key immutable once code references it — renaming the display name is safe, changing the key is not. Seeded examples used throughout these docs:

​
Targeting rules

A rule matches on attributes from the evaluation context — country, tenant, plan, userId, or any custom attribute you pass in. Each entry in conditions uses a discriminated union — exactly one of valueString, valueInt, or valueBool is populated, determined by valueType:
Example
logic: "and" means every condition in the array must match. A rule with two conditions and "logic": "or" matches if either one does — useful for something like “US-based or on the enterprise plan.”

​
Percentage rollouts

Rollouts split traffic after a flag is enabled and has no matching rule for a given request. Rollout assignment is deterministic via FNV-1a hashing — the same userId/tenantId always lands in the same bucket.
Example
If the bucketing key (userId for per_user, tenantId for per_tenant) is missing, the rollout treats the user as not in the rollout bucket — the flag falls through to its base value. Always pass the required attribute from your evaluation context.

​
If an SDK key leaks

1

Rotate the key for that environment

From the dashboard: Environment → Rotate key. This is the same environment you set up in Getting started, Step 1 — rotating only affects that one environment’s key, not others.
2

Update the key everywhere it's stored

Replace the value in your secrets manager or environment variable — the same FEATURE_FLAGS_SDK_KEY referenced in Getting started and Overview.
3

Redeploy or restart affected services

Any running process holding the old key in memory needs to pick up the new one.
4

Confirm the old key is dead

Try a call with the old key and confirm it now fails, rather than assuming rotation took effect.
This assumes rotation invalidates the previous key immediately, with no overlap window — worth confirming, since a zero-downtime rotation needs a different rollout order if there is a grace period.

​
Where this fits

Overview

The environment → flag → SDK key mental model, plus a first isEnabled() / useFeatureFlag() call.

Getting started

Ship new_dashboard end to end: create, enable, evaluate, verify.