Roles and Permissions
Access is role-based and Salesforce-driven. The app provisions users from Salesforce Contact fields, then gates UI and API behavior by role level and assigned divisions. This model exists because inspection creation, Salesforce submission, product mapping, pricebook updates, and Level 5 assignment have different operational risk profiles and should not be exposed through one flat permission.
Role ladder
| Role | Description |
|---|---|
| Level 1 | Field entry only: create inspections and capture photos/notes |
| Level 2 | Level 1 plus pricing visibility, Other Repairs, and own Salesforce submission |
| Level 3 | Level 2 plus same-division submission/review for other users |
| Level 4 | Level 3 plus Expert Mode and division-scoped setup tools |
| Level 5 | Full administrative access |
Permission model
Salesforce Contact fields ── provision ── app user
App user role ── gates ── screens and actions
Assigned division ── limits ── same-division review and setup
Explicit exception ── protects ── Level 5 assignmentAdministrative exception
Only sjohnson@amenitycollective.com should be able to assign Level 5 access.
Some production admin surfaces can be temporarily restricted to specific users regardless of role when a feature is operationally sensitive.
Pitfalls
- Do not assume Level 4 means unrestricted global administration; many setup tools remain division-scoped.
- Do not assign Level 5 through normal user editing paths unless the current user is the explicit Level 5 administrator.
- Do not evaluate access using only the UI; API routes also need to enforce the same permission boundaries.
Related pages
- Admin Tools lists the screens affected by elevated permissions.
- Salesforce Integration explains the Contact fields behind provisioning.
Last updated on