Skip to content

Brands & OAuth

Brands let you control the identity and login layer used across published experiences.

This matters when your public surfaces should feel like part of a specific business, team, or customer-facing brand rather than a generic shared workspace.

Brands page showing the empty state before any brand is created

What a brand is responsible for

A brand usually brings together:

  • brand identity, such as the name and visual assets
  • login configuration, including OAuth providers
  • the public experience that should inherit that identity

The basic flow

Start by creating the brand record.

Create Brand modal

Then continue with the rest of the setup:

  1. create the brand
  2. add the visual identity you want users to see
  3. configure the OAuth provider or login method you need
  4. use that brand in the published experience that should inherit it

When you actually need this

You do not need a brand for every pilot.

Use Brands & OAuth when:

  • the published experience should look like a specific customer-facing brand
  • you need a branded login flow
  • multiple workspaces should share the same public identity pattern

A practical rollout rule

Treat brand and login changes like publish changes:

  • make the configuration change deliberately
  • test the login or branded experience
  • only then broaden the rollout