Flag settings

Every field on a gate, what it changes, and when to reach for it.

Open Feature Management, then a gate, to see these.

Gate key

The exact string your code reads. Compared byte for byte.

Not to be confused with your API key, which is the secret credential your server authenticates with, or with the context key, which is the user identifier you pass when evaluating. This is the flag's own name.

Set it explicitly at creation. The form suggests a lowercased version of the display name, so a name of "checkoutRedesign" gives the gate key checkoutredesign unless you type the one you want.

A gate key cannot be edited afterwards — changing one means deleting the gate and creating it again — so this is the field worth thirty seconds of attention.

Name and description

For people, not code. The name is what the list shows; the description is where to say what the flag guards and when it can be removed. A flag with no stated exit condition tends to become permanent.

Flag type

BOOLEAN for on/off, which is most flags. STRING when you want to serve one of several named variations — a layout, a copy variant, a model name.

Default value

What the flag serves while it is disabled. Not a fallback for errors — the value a switched-off flag hands your application.

For a boolean gate you almost always want false, which is what a new gate starts with. Set it to something else only when "off" genuinely means a value other than false.

Per environment. Each environment holds its own default value, so the page labels it with the one you are looking at — "Default value in Staging".

Enabled

The on/off switch, and the one you will use daily. On serves true; off serves the Default value above.

The On / Off control on each row of the gate list does the same thing, which is usually quicker than opening the gate.

Per environment, and this is the field where that matters most. A flag is on in one environment and off in another; the switcher decides which one you are changing, and both the list and the flag page name it. If a toggle appears not to have worked, check the switcher before anything else.

Hide from client-side SDKs

Unticked by default, which means browsers can read the flag.

Leave it unticked for anything a browser reads — any flag reached from frontend code. The browser needs it, and this is also what makes a toggle reach an already-open page in about a second.

Tick it for a flag no browser needs: one only your backend reads, or one whose name gives something away before its value does. acquireCompetitorX leaks a plan whatever its value is.

What changes when it is ticked:

• Browsers are told nothing about the flag. It behaves for them exactly like a flag that does not exist — no value, and no socket updates.
• Your server is unaffected. The API key sees every gate either way.
• The value then changes on the next server render — the next request, the next revalidation, or a rebuild if the page is fully static — instead of reaching open pages immediately.

The reason this is a choice at all: live updates mean handing the flag to a credential anyone can read out of your bundle. Both are reasonable, so it is set per flag.

Rules

Targeting. A rule matches on the context your SDK passes — user id, email, country, or anything you send in attributes — and the first matching rule, by priority, decides the value.

Use rules for a percentage rollout, an internal-users-first release, or a per-segment difference.

Per environment. A rule created while you are looking at one environment belongs to it, is listed only there, and cannot affect another. There is no rule that spans environments.

See Rules and overrides for the attributes you can match on, the operators, how percentage bucketing works, and how to work out why a rule is not firing.

User overrides

A specific value for a specific user, checked before any rule. Two uses: putting one customer on a feature ahead of everyone, and pinning yourself to a variant while testing.

Overrides are matched on user id alone — the userId of the evaluation context — so pass a stable one for each user.

Per environment, like rules. Give each override a reason; it is the only thing that will explain the exception later.

Choosing values, quickly

Situation	Type	Default value	Hide from client-side SDKs
UI feature you want to toggle live	BOOLEAN	false	unticked
Backend routing decision	BOOLEAN	false	ticked
Flag whose name is sensitive	either	—	ticked
Copy or layout variant	STRING	the current variant	unticked
Kill switch for a UI feature	BOOLEAN	false	unticked