Feature flags

A feature flag turns a feature on or off, or changes a value, for the people using your app without a new release. Your developers add the flag to the app once; from then on you control it in Studio.

Create a flag

1. Open A/B testing → Feature flags and click New feature flag.
2. Enter the Slug your developers use, such as new-checkout. It must be unique in the project, archived flags included.
3. Add a Description of what the flag controls.
4. Choose the Type. It can't change later.
5. Click Create flag. The flag appears in the list; click it to open its page.

String, number and JSON flags need at least one variant, each with a Value and, except for JSON, an optional Label. People are split evenly between variants.

A new flag is Disabled, with a rollout of 0%. Changes on a flag's page apply only when you click Save changes.

Turn a flag on

A flag's status, targeting, overrides and history on one page

1. Set Status to Enabled.
2. For a Boolean flag, click the rollout next to Allocation and set the Rollout: the share of people who get it, in 1% steps.
3. Click Save changes.

Studio sets the rollout for Boolean flags only. For string, number and JSON flags, ask a developer to set it through the API or CLI (developer docs).

Archive and restore from the flag's menu. An archived flag keeps its slug.

Who gets the flag

For each person, Voidhash checks these in order and stops at the first that applies:

1. The flag is Disabled: off.
2. The person has an override: the overridden value.
3. The person is on the deny list: off.
4. There's an allow list and the person isn't on it: off.
5. Otherwise, the rollout decides: on for that share of people, off for the rest.

Each person keeps the same answer, and the same variant, until you change the flag. Raising the rollout only adds people; nobody who had the flag loses it. Someone who signs in may get a different answer than they had before signing in.

The same flag answers in every environment: production, sandbox and test.

Allow and deny lists

1. In Targeting, click Add a targeting rule (Add targeting rule once the flag has one).
2. Pick the List (Allow or Deny) and the Identity: Person ID, or App user ID for the ID your app signs people in with. Enter its Value.
3. Click Add rule, then Save changes on the flag.

• The deny list keeps people from getting the flag.
• The allow list limits the flag to the people on it. They still go through the rollout, so a 0% rollout gives them nothing. To guarantee someone the flag, use an override.

There are no rules by country, app version or other details. To compare paywalls, run an A/B test.

Overrides

An override pins a flag for one person, such as a tester.

1. In Overrides, click Add an override (Add override once the flag has one).
2. Choose the Identity type and enter its Value.
3. Switch Force enabled on or off, and add a Note (optional) saying why.
4. Click Add override, then Save changes on the flag.

Overrides beat the deny list and the rollout, but not a disabled flag. You can also add and remove a person's overrides on their profile in People; see Find and help a person.

History

Version counts changes to a flag's slug, name, description, status, rollout and variants. The change history at the bottom of the flag's page lists the flag's creation, changes to its slug, name, description, status and rollout, and archiving and restoring, each with the user ID of whoever made it, or System, and when; Changes shows the details.

Variant, allow and deny list, and override changes don't show there. They're kept in the audit log. Only admins and the owner can read either; Members see "Could not load activity." See Members and roles.

If something's off

• Nobody gets the flag: check it's Enabled, the rollout is above 0%, and you clicked Save changes.
• A tester doesn't get it: add an override for them; the allow list alone still applies the rollout.
• A change hasn't reached the app, or the flag isn't updating: apps pick up a change the next time they read the flag, usually within about 5 minutes.
• Create flag does nothing: the slug is already used in the project, archived flags included, or you're a Member.
• Save changes says you're not allowed: Members can open flags but not change them; see Members and roles.

Next steps

• Run an A/B test on a paywall
• Branch an automation on a flag
• Read flags in an app (developer docs)