Role-Based Access¶
Every member of an organization has one of four roles. Roles control what they can see and do across projects, wallets, and settings. Roles are checked on every protected action and on every API call.
1. The four roles¶
| Role | Level | Can do |
|---|---|---|
| Owner | 4 | Everything: rename or delete the org, manage billing, add/remove members at any level, change roles, manage subscriptions, transfer ownership. |
| Admin | 3 | Manage members and settings, create/delete projects, manage wallets, configure auto-recharge, manage Sentinel Passes and API keys. Cannot delete the org or transfer ownership. |
| Member | 2 | Use all projects in the org: create and edit assets, chat, run agents, publish to the marketplace where allowed. Cannot manage members or org-level settings. |
| Viewer | 1 | Read-only access to projects and assets they're granted. Cannot create, edit, install, or publish. |
The numeric level is enforced by the platform: higher-level roles automatically inherit lower-level permissions.
2. Project-level roles¶
Some actions are scoped to a project rather than the whole org. A project role cannot exceed your organization role — an org Viewer cannot be a project Admin.
3. Where roles are checked¶
- In the UI: hidden or disabled buttons reflect what your role allows. Actions you can't perform show a permission-denied toast if attempted.
- At the API layer: every backend call validates your role. Forbidden actions return
403 Forbidden; the UI auto-refreshes your permission cache and explains why.
4. Refresh permissions¶
Permissions are cached locally for up to five minutes. If you receive a permission change (promotion or demotion) and need it to apply immediately: 1. Switch organizations and switch back, or 2. Sign out and sign back in.
5. Common scenarios¶
- Promote an editor to admin: open Members, change role to Admin. Effective immediately for new actions; cached UI may take up to 5 min.
- Audit who can change billing: only Owners and Admins. Member and Viewer roles never see the billing or subscription UI.
- Restrict a contractor: invite as Viewer and grant Member only on specific projects.
For invite/remove flows, see Managing members. For settings actions only Owners can take, see Organization settings.
Mirrored from traylinx-web:docs/user-manuals/organizations/role_based_access.md. Edit the source in the traylinx-web repo — changes here are overwritten by the sync script.