Roles & Permissions
Control who can do what across your organization with granular role-based access control.
Overview
Xelon HQ uses a two-layer access control system:
- Roles determine which organizations a user can access.
- Permissions determine what a user can do within those organizations.
User Roles
Every user is assigned exactly one role. The role controls the scope of access across the organization hierarchy. See Organizations for details on the tenant hierarchy.
| Role | Organization Access | Use Case |
|---|---|---|
| HQ Root Admin | Automatic access to the main organization and all sub-organizations | Platform administrators, IT managers who need full oversight |
| Organization Admin | Access only to explicitly assigned organizations | Team members, project leads, or external users who only need access to specific tenants |
| No Access to any HQ | No platform access | API-only users (service tokens), or users whose access has been revoked |
The role determines which organizations a user can access. Permissions determine what actions they can perform within those organizations. A user with the Organization Admin role still needs specific permissions (e.g., allow_view_virtual_machines) to see resources in their assigned organizations.
Permissions
Permissions are granular action-level controls assigned to users. Permissions are additive — a user's effective access is the union of all permissions assigned to them. There is no explicit "deny" mechanism.
Permissions are generic and apply automatically to all organizations a user has access to. For example, if a user has allow_view_virtual_machines, they can see VMs in every organization they have been granted access to. There is no way to give a user different permissions per organization.
Permission Categories
Assigning Permissions to Users
Organization administrators with the manage permissions permission can assign or revoke permissions for any user in their organization:
- Navigate to Manage My Organization and select a user from the Users section.
- Select the user you want to configure.
- In the Permissions tab, check or uncheck the desired permissions.
- Click Save Changes to apply the updated permission set.
Permission changes take effect immediately. The user does not need to log out and back in — the next page load or API request will reflect the updated access level.
Be cautious when granting the manage permissions permission. Users with this permission can escalate their own access or the access of others within the organization.
Best Practices
- Principle of Least Privilege — Grant only the permissions each user needs to perform their role. Avoid assigning broad permissions unless necessary.
- Regular Audits — Periodically review user permissions to ensure they remain appropriate, especially after team changes or role transitions.
- Document Roles — Define standard permission sets for common roles (e.g., Developer, Operator, Billing Manager) and apply them consistently across users.