Application branding

Each application can show its own logo, colors, and background on the sign-in screen, overriding the tenant/admin "root" defaults.

Precedence

Effective precedence, per field:

application-level  >  tenant / admin-root  >  native default  >  org-portal (fallback)

• The server merges branding as application > tenant, so per-app branding wins over the tenant defaults.
• If a portal-branding layer is configured, it only fills gaps (fields nothing else set) — it never overrides application or tenant branding.

Set application branding

Admin console → open an Application → Branding tab → enable branding and set:

• Logo (light / dark) and favicon
• Brand color (light / dark)
• Background color (light / dark) and Background image URL

Leave a field empty to fall back to the tenant/root default.

Requirements for per-app branding to show

• The application must not be third-party (per-app branding is intentionally skipped for third-party apps).
• The login must be initiated with that app's client_id so the app context (app_id) reaches the sign-in screen — the SDK does this automatically.

Background

Background color (light/dark) and a background image URL are supported per application (and per tenant). Because the fields live on the shared branding object, a per-application background overrides the tenant default automatically. Provide an https: image URL, or a hex color.

Tenant-level defaults

Set tenant-wide branding in Sign-in experience → Branding. Applications that set their own branding override these; applications that don't inherit them.

Best practices

• Use tenant branding as the default look, and application branding only where a product needs a distinct identity.
• Keep contrast accessible (AA) — a custom background/color must not make text or the primary button unreadable.
• Serve logos/backgrounds over HTTPS; URLs are validated (https/hex).