How access control works
Three independent checks run on every action, and all three must pass.
| Check | Question | Decided by |
|---|---|---|
| Authentication | Who are you? | Your session |
| Permission | Is this person allowed to? | Your role |
| Capability | Is this organization's plan allowed to? | The plan |
A Viewer on Cosmos still cannot delete an asset. An Owner on Nova still cannot open the Executive Dashboard.
Roles
Five roles, each holding an explicit set of permissions:
| Role | Broadly can |
|---|---|
| Owner | Everything, including users, organization settings, and billing |
| Admin | Full asset, category, and maintenance management; read users; no user management |
| Manager | Create and update assets, assign, manage maintenance, view reports; no deletion |
| Employee | Read and update assets, complete maintenance, check items out and in |
| Viewer | Read assets, categories, departments, and checkouts |
Full detail: Roles and permissions.
Changes take effect immediately
Role, plan, deactivation, and organization status are re-read from the database on every request — not at next sign-in.
That means:
- Revoking a role takes effect on that user's next request
- Deactivating a user ends their access immediately, including mid-session
- Deleting a user invalidates their session immediately
There is never a window where someone keeps permissions they no longer hold because their session has not expired.
Your organization's data is isolated
Every query filters by an organization identifier that came from the server. Organization identity is never accepted from the browser or from an API request body.
- Interactive requests take it from your authenticated session
- API requests take it from the API key record, resolved server-side
- Files are stored under a per-organization prefix
There is no way for a request to reach another organization's data, including through the API.
API access
API keys carry their own granular permissions, independent of user roles. Every request passes through the same sequence: size check, key authentication, plan gate, permission scope, then the handler — with an audit log written whether the request succeeded or failed.
Keys can be restricted by IP address, and revocation is immediate.
See API security.
Platform staff access
Access for support and plan administration is granted by an allowlist held in configuration — not by a flag in the database that could be changed through the application.
Actions taken by platform staff on an organization are written to an internal audit log.
Fail closed
Where access cannot be established, it is denied rather than assumed:
- A missing organization resolves to the most restrictive plan
- An authorization record that cannot be read denies access rather than falling back to older claims
- Availability yields to correctness here, because silently serving revoked permissions is the failure this design exists to prevent
What you control
- Assign the minimum role each person needs. Most people asking for more access need Manager, not Admin.
- Deactivate leavers promptly. It is immediate, and it preserves their history.
- Give each integration its own API key with the minimum scopes.
- Review sign-in history on your profile.
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support