The owner dashboard has one team-management surface, at Owner Dashboard → Settings → Team permissions. It's owner-tier-only and it controls what your tenant admins can do in the owner dashboard — billing, branding, custom domains, API keys, audit log. Day-to-day operations staff (dispatchers, support agents, KYC reviewers) are added in the ops console under Staff, which is a separate page in a separate app. Don't mix them up.
The role model
There are two tenant-tier roles in the identity service:
| Role (enum) | What it is |
|---|---|
TENANT_OWNER | The founder / billing-responsible person. Exactly one per tenant — enforced by a partial unique index on the roles table. Always has every permission, regardless of the Team-permissions grid. |
TENANT_ADMIN | A non-Owner admin. Their permissions are whatever the Owner has ticked in the Team-permissions grid for this tenant. |
A third role, PLATFORM_ADMIN, exists for BetterSuite staff who occasionally impersonate a tenant for support — it passes the same gates as TENANT_OWNER for in-product checks.
There are no separate "Operator" / "Viewer" / "Manager" roles in the owner dashboard. The granularity comes from the permission set described below.
The Team-permissions grid
Owner Dashboard → Settings → Team permissions renders a checkbox grid keyed by the TenantSettingsPermissions enum. The grid edits the shared default for the tenant — every TENANT_ADMIN in this tenant uses the same set. Per-account overrides are a planned future phase; today, what you tick here applies to all your admins at once.
The grid renders in this order:
| Permission | What it grants |
|---|---|
| View billing | Read invoices, plan, status — no changes. |
| Manage billing | Change plans, cancel, reactivate, manage add-ons. |
| Manage branding | Edit colors, logos, vertical-specific assets. |
| Manage custom domains | Add, remove, verify custom domains for tenant apps. |
| Manage API keys | Issue, rotate, revoke API keys. |
| Manage connected apps | Install and remove integration connections. |
| Manage users | Invite, remove, and change roles for tenant admins. |
| View audit log | Read the tenant audit log. |
| Manage audit retention | Change how long audit-log entries are kept. |
| Delete tenant | Self-delete the tenant. Owner-only in practice. |
Owners always have every permission; the toggles only constrain non-Owner admins. Click Save changes at the bottom to commit. If you have unsaved edits the button activates and the page reminds you with "You have unsaved changes."
Where invites, role changes, and removal happen
The owner dashboard does not ship an invite form or a member list today. The Settings page renders two cards — Passkeys for your own account, and Team permissions (Owner-only) — and a button to Open Admin Console. That's it.
The full member workflow — invite, accept, change role, remove, suspend — lives in the ops console at <your-slug>-admin.bettersuite.io under Management Common → Staff. That's where you actually add a person to the tenant; the owner-dashboard grid then shapes what they can see in the owner dashboard once they're in.
MANAGE_USERS in the grid is the toggle that gates whether a TENANT_ADMIN can perform those staff mutations themselves (in the ops console). Owners always can.
Transferring ownership
There's a transfer_tenant_ownership use case in the identity service that demotes the current Owner to Admin and promotes a target Admin to Owner in a single transaction. It's surfaced through the ops console (not the owner dashboard's Settings page). The target must already be a TENANT_ADMIN in the same tenant; you can't transfer to someone outside the tenant.
Audit log
Every sensitive action against the owner dashboard — adding a custom domain, removing a custom domain, changing the auth policy, editing the permission grid — writes a row to the audit log at /dashboard/audit-log. The page is searchable and gated by VIEW_AUDIT_LOG; retention is gated by MANAGE_AUDIT_RETENTION.
I couldn't verify a specific retention default in the implementation — the policy is editable per tenant rather than hard-coded.
Passkey policy is configured separately
Tenant-wide auth policy (passkey requirement, session length, MFA) lives at Owner Dashboard → Sign-in & Auth, not on the Team page. Turning on passkey enforcement there applies to every account in the tenant — including the Owner. Set it up while the team is small to avoid retrofitting passkeys onto people who've already enrolled with passwords.
What's next
- Plans & Billing —
MANAGE_BILLINGis what gates non-Owner admins on this page. - Custom Domains —
MANAGE_DOMAINSplus a step-up password. - Dashboard Tour — owner dashboard vs. ops console, and why team management spans both.
