Roles and access
The platform uses role-based access. A role is a named bundle of permissions assigned to a member; it decides which parts of the platform a person can reach and which actions they can take. This guide describes the roles at a user altitude.
The roles
| Role | What it can see and do |
|---|---|
| Tenant admin | Full workspace access, including team settings, integrations, billing, and the audit log. |
| Dispatcher | Dispatch operations: the active-trips queue, alerts, and the fleet roster. |
| Driver | A minimum-necessary view: just the asset, status, and site detail a driver needs. |
| Billing | The usage ledger and billing detail. |
| Auditor | Read the audit log. No data changes. |
| Tenant switcher | Switches the active workspace for an account enabled to work across more than one workspace. Granted separately from the roles above; most accounts do not have it. See Switching between workspaces. |
Project-scoped access
Beyond roles, access can be scoped to a project. A project is private to its owner by default and can be shared so anyone in your workspace can read it. Reference files in a project follow the same visibility. See Projects.
How access is enforced
Your role and your active workspace are resolved on the server for every request, never chosen by the browser. That is why you cannot widen your own access by changing something on the page: the decision is made server-side, and every access is recorded in the audit log.
Switching between workspaces
If your account is enabled to work across more than one workspace, you can switch the active workspace. When you switch, everything follows the new scope: the records you see, your chats, the audit log, and usage all change together. The active workspace is the one the server resolved for you, so the switch is validated server-side.
See also
- Access and audit for the public posture.
- Invite your team for assigning roles during onboarding.