Permissions
Every permission in XBuddy is a flat string of the form resource:action — a capability, e.g. invoices:write, leads:read, payroll:approve. Roles hold sets of these capabilities; users get them by holding roles.
Standard action verbs
The action verb is standardized across the platform:
| Verb | Meaning |
|---|---|
read | View lists and detail |
write | Create and edit |
delete | Delete or archive |
approve | Approve in a maker-checker flow |
manage | Configure the resource’s own settings |
export | Export data out of XBuddy |
use | Use a feature that isn’t CRUD (e.g. ai:use, pos:use) |
monitor / review | Oversee or review (AI suggestions, agents) |
Scope (own/team/all) is not encoded in the permission name — which records a permission applies to is a separate setting. See Data Scope.
How permissions gate the product
The same capability is enforced at every layer:
- Menus & navigation — apps and menu items a user lacks permission for are hidden from their sidebar.
- Pages & buttons — action buttons (Create, Approve, Delete, Export…) only appear when the user holds the matching permission.
- The server (the real boundary) — every API request is checked again on the server. Hiding a button is convenience; the server-side check is the security guarantee. A response never contains data the user isn’t allowed to see.
Deny-by-default applies throughout: if a capability isn’t granted by any of the user’s roles, the action is refused.
Maker-checker: creator ≠ approver
For financial and legal documents (invoices, bills, payments, contracts…), approve is deliberately a separate verb from write. This enables separation of duties: the person who creates a document should not be the one who approves it. XBuddy enforces this on approval flows — an approver cannot approve their own submission.
Grant approve sparingly, and to different people than those doing data entry. Combined with the audit trail, this is your main internal control on financial documents.
Sensitive permissions to watch
export— lets data leave XBuddy; grant only where genuinely needed.delete— separated fromwritebecause of its risk; most day-to-day roles don’t need it.manage— configuration power over a resource, above ordinarywrite.adminrole (*) — every permission; reserve for one or two trusted administrators.