Roles & Permissions
Control exactly what each team member can see and do. Breadbox ships with 7 roles designed for MSP org structures — customize any of them or create your own.
Permission model
Permissions are defined as resource + action pairs. Each role has a set of granted permissions, and each permission has a scope that controls which records within that resource the user can access.
Resources
accounts, contacts, contracts, deals, leads, QBRs, touchpoints, assessments, compliance, onboarding, reconciliation, devices, partners, vendors, workflows, reports, profitability, licenses, integrations, settings, users
Actions
view, create, edit, delete, export
Special: settings.manage, users.manage, integrations.manage, workflows.activate, admin.full_access
Scopes
ALL — see every record in the org
ASSIGNED — only records assigned to this user
NONE — explicitly denied
Default roles and permissions
Full access to everything. Cannot be restricted. Only admins can manage users, configure integrations, and change billing.
admin.full_access — bypasses all permission checks
Manages assigned client relationships.
- accounts: view (ASSIGNED), edit (ASSIGNED)
- contacts: view (ALL), create, edit
- contracts: view (ASSIGNED), edit (ASSIGNED)
- deals: view (ASSIGNED), create, edit
- QBRs: view (ASSIGNED), create, edit
- touchpoints: view (ASSIGNED), create, edit
- assessments: view (ASSIGNED), edit
- compliance: view (ASSIGNED), edit
- reports: view (ASSIGNED)
- profitability: view (ASSIGNED)
Works new logo pipeline and prospect management.
- accounts: view (ALL) — read only
- contacts: view (ALL), create, edit
- deals: view (ASSIGNED), create, edit, delete
- leads: view (ASSIGNED), create, edit, delete, convert
- partners: view (ALL), create, edit
- assessments: view (ALL), create, edit
- reports: view (ASSIGNED)
Strategic advisory — assessments, compliance, technology roadmaps.
- accounts: view (ASSIGNED), edit (ASSIGNED)
- contacts: view (ALL)
- assessments: view (ALL), create, edit
- compliance: view (ALL), create, edit
- QBRs: view (ASSIGNED), create, edit
- touchpoints: view (ASSIGNED), create
- reports: view (ALL)
- profitability: view (ASSIGNED)
Oversees service delivery, onboarding, and reconciliation.
- accounts: view (ALL)
- onboarding: view (ALL), create, edit
- reconciliation: view (ALL), edit
- devices: view (ALL)
- reports: view (ALL)
Day-to-day technical work on assigned accounts.
- accounts: view (ASSIGNED)
- contacts: view (ASSIGNED)
- devices: view (ASSIGNED)
- touchpoints: create (for logging site visits)
- compliance: view (ASSIGNED), edit (ASSIGNED) — only items assigned to them
Read-only access to all records. Cannot create, edit, delete, or export.
All resources: view (ALL). No mutations of any kind.
Customizing default role permissions
Go to Settings → Roles & Permissions. Click any role to edit its permissions. You can change the scope (ALL → ASSIGNED or vice versa) or toggle actions on/off for any resource.
Changes take effect immediately. Team members don't need to log out.
Creating custom roles
Click New Role in Settings → Roles & Permissions. Custom roles start with no permissions — grant each resource/action/scope you want explicitly. Give the role a name and key (e.g., operations_manager).
Custom roles have isSystem: false and can be fully deleted. System roles (the 7 defaults) can be modified but not deleted.
Why the Viewer role can't be elevated
The Viewer role has a hardcoded isViewerOnly: trueflag that blocks all mutations at the middleware level — regardless of what permissions are configured. This provides a trustworthy guarantee: anyone given the Viewer role truly cannot modify any data. If you need a Viewer who can also create touchpoints, create a custom role instead.