Team management lives under Account in the dashboard sidebar, in two pages: Staff (the people) and Roles (what each role can see and change). It covers everyone who works in the console. The admin who handles branding and the dispatcher who runs the live map are added the same way, in the same place, and differ only in the role they hold.
Your staff can sign in at bettersuite.io/dashboard or at your own console address, <your-slug>-admin.bettersuite.io — it's the same console and the same account either way. See Dashboard Tour.
The role model
There are two workspace-tier roles in the identity service:
| Role (enum) | What it is |
|---|---|
TENANT_OWNER | The founder / billing-responsible person. Exactly one per workspace — enforced by a partial unique index on the roles table. Always has every permission, regardless of any staff role. |
TENANT_ADMIN | A staff member. What they can do is whatever their staff role grants. |
A third role, PLATFORM_ADMIN, exists for BetterSuite staff who occasionally impersonate a workspace for support — it passes the same gates as TENANT_OWNER for in-product checks.
Staff roles are yours to define. Create as many as you need — a Dispatcher role, a Support role, a Finance role — and give each exactly the permissions the job requires.
Roles and permissions
Account → Roles lists your roles with the number of permissions each grants. New role asks for a name, a short code (fixed once the role is created), an optional description, and the permissions.
Permissions are grouped:
| Group | What it covers |
|---|---|
| People | Accounts, roles, API keys and groups. |
| Dashboard | The dashboard itself, its configuration and logs. |
| Taxi | Rides, drivers and vehicles. |
| Shop | Products, orders and inventory. |
| Parking | Spaces, lots and bookings. |
| Services | Services, bookings and providers. |
| Analytics | Reports, metrics and data exports. |
| Workspace settings | Billing, domains, integrations, the audit log and other sensitive settings. |
Groups for services you don't run are hidden. On an existing role, changes apply to everyone holding it as soon as you make them.
The Workspace settings group is keyed by the TenantSettingsPermissions enum, and only the Owner can change it on a role:
| 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 your 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 workspace admins. |
| View the audit log | Read the workspace audit log. |
| Manage audit log retention | Change how long audit-log entries are kept. |
| Delete the workspace | Self-delete the workspace. Owner-only in practice. |
| Configure / Run / View data sync | Set up, run, and read migrations. |
Owners always have every permission; roles only shape what other staff can do. A handful of pages stay Owner-only whatever a role grants — Billing, Custom Domains, API Keys, PSP Accounts, Payout Methods, SMS Providers, Social sign-in and Testers — because they hold payment details or credentials.
Where invites, role changes, and removal happen
All of it is in Account → Staff.
- Add someone — New staff member, then their email and a role. They sign in to the dashboard with that email; set a password for them from their page once they're added, or they can reset it themselves from the sign-in screen.
- Change their role — open the staff member and pick another role. Only the Owner can change another staff member's role, and nobody can change their own.
- Block — signs them out and stops them signing in to the dashboard, or to any of your apps, until you unblock them.
- Remove access — they lose their role and can no longer use the dashboard. The account stays, so you can give them access again later.
A staff member's page also lists the devices they're signed in on.
Transferring ownership
The Owner hands the workspace to another admin from Settings → Ownership. It runs the transfer_tenant_ownership use case in the identity service, which demotes the current Owner to Admin and promotes the target Admin to Owner in a single transaction, and it asks for your password first. The target must already be an active admin of the same workspace; you can't transfer to someone outside it. Afterwards only the new Owner can hand ownership back. The plan and payment method stay as they are.
Audit log
Every sensitive action in the dashboard — adding a custom domain, removing a custom domain, changing the auth policy — 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 workspace rather than hard-coded.
Passkey policy is configured separately
Workspace-wide auth policy (passkey requirement, session length, MFA) lives at Settings → Sign-in & Auth, not on the Staff page. Turning on passkey enforcement there applies to every account in the workspace — 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 — the Billing page is Owner-only.
- Custom Domains — Owner-only, plus a step-up password.
- Dashboard Tour — the whole sidebar, and the two addresses the console answers on.
