Users & Permissions
XBuddy controls access with a role-based model. You never grant permissions to a user directly — instead you build roles that hold permissions, and assign roles to users. This keeps access consistent and auditable: change a role once and everyone holding it updates.
Every request a user makes is checked against four independent questions. A request is allowed only when it passes all of them:
| # | Question | Answered by |
|---|---|---|
| 1 | Who is this user? | User accounts — identity, account type, active/inactive |
| 2 | What can they do? | Roles and their resource:action permissions |
| 3 | On which records? | Data scope per resource (none / own / team / all) |
| 4 | In which apps? | Your subscription packs, plus a per-user app allowlist |
The questions are AND-ed together: buying the CRM pack doesn’t grant anyone the right to edit leads, and having permission to read deals with own scope still only shows the deals you own. The server enforces every layer — the interface hides things only for convenience.
Configure each layer
Where things live
- Settings → Users (
/settings/users) — invite and manage user accounts, assign roles, set account type and app access. - Settings → Roles (
/settings/roles) — create roles, grant permissions, and set data scope per resource.
Verify access
Use the Permission Audit view to check exactly what a user can do. Always confirm a new role by logging in as a test user with only that role before rolling it out.