Sign in

Open the dashboard URL and click Continue with Google. Only @codazen.com Google 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 three stage chips on each row (local / staging / prod) show where the flag is currently on; faded chips mean off in that stage.

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 Save button 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 history card 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).

• prod — the live production deployment. Every user is affected.

• staging — the staging deployment, internal validation only. Flip here first to verify before promoting to prod.

• local — every developer running the app on their laptop with STAGE=local. Useful for centrally toggling work-in-progress features for the whole engineering team during dogfooding.

Common pattern: enable local first → engineers dogfood → enable staging for broader internal validation → enable prod when ready to ship. Roll back is just unticking the prod box and saving with a note.