How access is decided
- 1
Check the company role
Admin, Manager, Supervisor, or Employee defines the user’s broad capability.
- 2
Check project assignment
For non-Admins, the user must normally be actively assigned to the project.
- 3
Check module access
Optional workflows require the related module to be active for the company.
- 4
Check the record
Ownership, status, approval state, project condition, and other record rules can still block the action.
Core role comparison
| Role | Typical access |
|---|---|
| Admin | Company-wide administration, all projects, settings, users, reports, collections, subscriptions/modules, and Admin approvals. |
| Manager | Assigned-project management and permitted project operations; no company settings or company-wide billing/module administration. |
| Supervisor | Assigned-project operational and field review with limited financial visibility; generally no central approval authority. |
| Employee | Own attendance, assigned work, and supported submissions; no company-wide administration. |
Important approval boundaries
- Managers can approve eligible labor only within current project and role rules.
- Managers cannot approve project expenses.
- Supervisors and Employees generally submit records rather than approve them.
- Admin approval is still subject to module rules, record state, and other workflow safeguards.
Assignment does not upgrade a role
Optional modules add another gate
Materials, Payroll, Quotations, Kiosk Attendance, Budget Releases, Office Budget, Custom Branding, and other add-ons are available only when the company has the required entitlement and the user’s role supports the action.
Important notes
- Use the lowest company role that provides the access the person needs.
- Navigation visibility is not the only protection; server-side checks enforce access independently.
- Project assignment narrows access but does not replace the company role.