Understanding Permissions

The One Stack uses a two-level permission model: Hub org roles control broad access, and product-level permissions control what users can do within each product.

Hub Org Roles

Every user in your organization has exactly one Hub org role:

Role	What They Can Do
Owner	Full access to everything. Can manage billing, delete the org, and transfer ownership. Only one owner per org.
Admin	Full access to all products. Can manage users, roles, and permissions. Cannot delete the org or transfer ownership.
Member	Access to products based on their product-level permissions. The default role for most technicians.
Billing	Access to Books and billing settings only. Cannot access operational products. Designed for accounting staff.
Viewer	Read-only access across all products they're granted access to. Cannot create, edit, or delete anything.

Product-Level Permissions

Within each product, permissions are granular. There are 640+ individual permissions across 26 products. Permissions follow a consistent pattern:

product.resource.action

Examples:

• psa.tickets.create — Create new tickets in PSA
• crm.contacts.edit — Edit contacts in CRM
• defend.alerts.acknowledge — Acknowledge security alerts in Defend
• books.invoices.void — Void invoices in Books
• rmm.scripts.execute — Run scripts on endpoints via RMM

How Roles and Permissions Interact

Your Hub org role sets the ceiling; product permissions set the specifics.

• Owner / Admin — Automatically have all product permissions. No additional configuration needed.
• Member — Must be explicitly granted product permissions. A member with no product permissions can log in but can't do anything useful.
• Billing — Only has access to Books-related permissions regardless of any product permissions assigned.
• Viewer — All granted permissions are downgraded to read-only automatically.

Managing Permissions

Granting Access

1. Go to Hub → Users
2. Select the user
3. Click Permissions
4. Toggle individual permissions or use permission groups (preconfigured sets like "Technician", "Dispatcher", "Sales Rep")

Permission Groups

Permission groups are templates that bundle common permissions together:

• Technician — PSA tickets, RMM endpoints, Defend alerts, Backups management
• Dispatcher — PSA tickets and scheduling, no endpoint access
• Sales Rep — CRM full access, PSA read-only, Books invoices read-only
• Manager — Everything in Technician plus reporting, People HR, and Projects
• Client Admin — Portal access, ticket submission, report viewing (for your MSP clients)

You can create custom permission groups that match your organization's roles.

Revoking Access

Remove individual permissions or remove the user from a permission group. Changes take effect immediately — the user's next API call or page load will reflect the new permissions.

Client vs. Staff Permissions

The One Stack distinguishes between two permission scopes:

• Staff permissions — For your MSP employees. Access is scoped to the entire organization's data.
• Client permissions — For your MSP clients (via Portal). Access is scoped to only their company's data.

A client user with psa.tickets.create can only create tickets for their own company. A staff user with the same permission can create tickets for any client.

This scoping is automatic and enforced at the API level — there's no way for a client user to access another client's data.

Best Practices

• Start with permission groups rather than individual permissions. It's easier to manage 5 groups than 640 individual toggles.
• Use the Viewer role for stakeholders who need visibility but shouldn't make changes.
• Audit permissions quarterly — Hub provides a permission audit report showing who has access to what.
• Use the Billing role for accountants — it prevents accidental access to operational data.