See It Evaluate
The last step of the quickstart, and the one that shows why flags are worth the setup: changing behaviour without shipping code.
Change the value, watch your app follow
Flip it
Open the flag, switch it off in the environment your app is using, and press Publish changes.
Reload your app
The value your code reads has changed. No deploy, no restart, no code edit.
Flip it back
Turn it on again and publish. This is the loop you will use for every rollout from here on.
- Switch the flag on or off for the environment you are testing.
- Press Publish changes to send it to your SDKs. Nothing reaches your app until you do this.
That is the whole promise. Everything else is about being more precise on who gets which value.
Make it apply to some people and not others
Until now the flag returns the same value to everybody in an environment. A rule narrows that.
Open the flag, choose an environment, and press Add Rule. There are two kinds:
| Rule | What it does | Use it for |
|---|---|---|
| Targeted delivery | Gives a chosen value to people who match an audience | Beta groups, internal users, one country, a percentage rollout |
| A/B test | Splits matching people across variations and measures a metric | Deciding which value actually performs better |
- Targeted Delivery serves one chosen value to whoever matches your audience.
- A/B Test splits matching people across variations and measures the result.
Rules read the attributes you passed when you initialised the SDK, so a rule that
targets plan = premium only works if your app tells us the plan. If a rule is not
matching anyone, that is the first thing to check.
Rules are evaluated in order, top to bottom, and the first match wins. Anyone who matches nothing gets the flag's default variation. The ordering controls and the full lifecycle of a rule are covered in Managing Rules and Rule Statuses.
How to tell it is really evaluating
There are three honest signals, in increasing order of certainty:
- Connection status. The Environments page says Connected when an SDK checked in during the last 5 minutes. That proves the SDK is reaching us and reading configuration.
- Your own application. The value your code receives changed after you published, which proves the whole path end to end.
- Rule results. An A/B test rule collects statistics you can read in the flag's results view, which proves people are being bucketed and measured. See Viewing Rule Results.
A brand-new rule with no data has not gone wrong. Flags only evaluate when your code asks, so the numbers start moving when real users hit the path the flag guards.
If your code checks flag.isEnabled(), know that a rule match is only one of
six ways it can come back true. A holdout, a bandit, a sticky assignment, and
an override (one set from the dashboard, one set by your own code at
runtime) all count as real decisions too. It only comes back false when
nothing decided anything: the value is falsy, or no datafile was ready yet
to ask.
Where to go next
- Type safety. You can generate TypeScript types for your flag keys and values so a renamed flag becomes a compile error instead of a silent default. See Typed contexts and generated types.
- Scheduling. Turn a flag on or off at a chosen time without being awake for it: Scheduling.
- History and rollback. Every publish is recorded, and you can roll an environment back to any earlier version: History and Restore.
- Everything else. Flag types, evaluation order, statuses and variations in full: Feature Flag Concepts.
You are done
Your account, organization, project, SDK, first flag and first rule are all in place. The getting-started checklist on your dashboard should now be complete, and it will disappear on its own.