Organizations, roles and staff
How tenants, client codes, organization roles and Dylog staff fit together.
Organization = tenant
Every customer is an organization. It has a display name, a URL slug (letters, digits, -, _) and
metadata with the one field backends care about:
{ "client-code": "SSD_JKLMNBVCXZA" }The client code is minted when staff create the organization (first word of the name plus eleven random
letters) and is never editable from the UI. It reaches backends as the JWT claim org_meta["client-code"]
and is the key for gateway and analytics data. The slug is only a label for URLs.
Roles inside an organization
| Role | Can |
|---|---|
owner | Everything below, plus update the organization and manage other owners |
admin | Invite, remove and re-role members (below owner), manage organization API keys |
member | See the organization, its people and its client code; read API keys |
Permissions are declared once in src/lib/auth-shared/access.ts and enforced on both the server and the UI.
Two Dylog-specific resources extend the Better Auth defaults: apikey (create, read, delete) and tenant
(read the client code).
Dylog staff are super users
A user whose account role contains admin is staff. Staff:
- administer users and tenants from the Better Auth Infra dashboard;
- are the only people who can create organizations;
- hold an automatic
ownermembership in every organization, so every organization page, member list, invitation and API key is visible and manageable to them. Tenants cannot remove or downgrade those memberships (the API answers403 STAFF_MEMBERSHIP); - can ban users and impersonate them for thirty minutes to reproduce an issue;
- carry
is_staff: truein every JWT, alongside the claims of whichever organization is active.
Staff memberships are kept in sync automatically: when an organization is created, when staff sign in, and when someone is promoted or demoted.
Active organization
Each session remembers an active organization, defaulting to the user's first membership at sign-in.
The generic /api/auth/token endpoint mints claims for that organization. Multi-organization users and
services should prefer /api/token?org=<slug>, which names the organization explicitly.