Roles and tiers
Understand who can do what and how plan tier affects available modules.
Roles decide what a user can do. Plan tier and feature controls decide which modules are available to the organization.
Access is effective only when every applicable check passes:
- The user's role can open or change the feature.
- Admins are responsible for the affected job site directly or through a job-site group.
- The organization's plan includes the parent feature or subfeature.
- The feature is enabled for the organization.
Roles
| Role | Best for | Typical access |
|---|---|---|
| Worker | Field employees | Worker dashboard, own timecards, certifications, toolbox talks, documents, messages, notifications, and time-off requests |
| PM | Project managers | Admin dashboard, job sites, certifications, compliance monitoring, toolbox talks, messages, pending approvals, and calendar when enabled |
| Superintendent | Field operations role, where enabled | PM-style access plus admin timecard list/detail visibility |
| Admin | Job-site operators | Operational access for assigned job sites and job-site groups, including responsible workers, timecards, records, and reports |
| Owner | Organization leaders | Full organization administration, settings, permissions, roles, Admin responsibility, worker lifecycle, recent-action recovery, reports, and billing-sensitive operations |
| Dev | Site Secure operations | Internal support access, cross-organization diagnostics, dev admin portal, view switching, and test controls |
Give users the narrowest role that fits their job. Upgrade access only when the person needs the additional responsibility.
Plan tiers
Each tier inherits the tiers below it.