Sign in

Open the dashboard URL and click Continue with Google. Only @codazen.comGoogle accounts can sign in — anything else is rejected at the OAuth step. The session lasts 24 hours; after that you'll re-auth silently if you're already signed into Google.

Navigating

The left sidebar lists every scope (the app each flag set belongs to — harmonica, codazen-website, etc.). Click a scope to see its flags in the main pane. Use the search box at the top of the sidebar to filter scopes by fuzzy-subsequence match (e.g. typing hm matches harmonica).

Inside a scope, the second search box (under the title) filters that scope's flags by the same fuzzy match on flag name. The stage chips on each row show where the flag is currently on; faded chips mean off in that stage. A dashed chip means the flag reaches that ring via a wider one in the same deployment, rather than being ticked for it directly.

Adding a new scope

You can't create a new scope from this dashboard. A scope corresponds to an application that reads feature flags at runtime, so adding one always requires a codebase change in the consuming app. If you need a new scope, ask the engineering team to add it — once the consuming app is shipping with the new scope wired up, you'll be able to create flags in it from here.

Existing scopes appear in the sidebar automatically. Suggested scopes (greyed-out entries with 0 flags) are pre-populated for convenience; they become "real" the moment you create the first flag in them.

Creating a flag

From any scope page, click Create flag in the top-right of the title row. Fill in:

• Name (required) — lowercase letters, digits, dashes, underscores. Must be unique within the scope.

• Description(optional) — plain English, "what does this flag gate?".

• Enabled in— tick the stages where you want it on at creation time. All off is fine; you'll flip stages later from the detail page.

• Change note(required) — short rationale, e.g. "creating for ramp of new onboarding flow". Recorded as the first history entry.

Hit Create. The flag appears in the table with the stages you picked, and the scope's flag count goes up by one in the sidebar.

Editing a flag

Click any row in the flag table to open its detail page. From there you can edit the description and toggle stages on or off via the Enabled in checkboxes. Every save requires a non-empty Change note— there's no way to skip it. The note explains why you made the change and goes into the audit trail.

The Savebutton stays disabled until something has actually changed, so you won't accidentally write a no-op. After save, the page refreshes with the new state and a new history entry appears at the top of the history card.

Reading history

The detail page's Recent historycard shows the last 10 changes, newest first. Each entry has the user's email, a relative timestamp (hover for exact time), the before → after stage list, and the change note. Identity comes from the verified Google session — it's never self-reported by the client, so theupdatedBy column is trustworthy for incident reviews.

Stages — what each one means

Stages model where a flag is on at runtime, not which environment owns the data (every stage reads from the same shared table). They come in two kinds.

Deployment targets — where a process runs

• staging — the staging deployment, internal validation only.

• local — every developer running the app on their laptop with STAGE=local. Local has no rings; use the FF_<NAME> env override there instead.

• prod — the live production deployment.

These are independent of each other. A flag on for staging is not reachable from production, and vice versa.

Early-access rings — who sees it within one deployment

• beta / staging-beta— users who opted into Beta, plus Alpha users. Not the deployment's general audience.

• alpha / staging-alpha — Alpha users only. The narrowest audience.

Rings nest within their deployment: alpha ⊇ beta ⊇ general. Ticking the general audience automatically covers Beta and Alpha, so tick only the narrowest ring a feature should reach — you never have to re-tick the wider ones.

Rings never cross deployments. Ticking staging-beta reaches beta users on staging and nobody on production — that is what lets you rehearse the full ladder in staging first. Users choose their own ring, and STAGE=alpha is not a valid deployment value.

Common pattern: local → staging-alpha → staging-beta → staging → alpha → beta → prod. Roll back by moving the tick back inward, or unticking entirely, and saving with a note.