Roles & permissions
Tero.Ops does not ship a fixed list of job-title roles. Access is granted by company roles that your company builds itself, from a grid of individual permissions.
Company roles
A company role has a name, a description, and a set of permissions. Company admins create and edit roles under Roles, at the top of the sidebar, and assign them to people on the Users page.
Because roles are defined per company, two companies using Tero can have completely different role names and completely different access — there is no shared, standard set to look up.
The permission grid
A role’s permissions are chosen in a grid. Each row is a collection of data, and each row offers up to four permissions, plus a Select All box to tick them all at once:
| Permission | What it allows |
|---|---|
| Read | See the records |
| Create | Add new records |
| Update | Change existing records |
| Delete | Remove records |
The rows are grouped so related collections sit together:
- Tasks & Jobs
- Orders & Inventory
- Assets & Meters
- People & Access
- Projects
- Other
Tick exactly the boxes the role should have. A role that can read jobs but not change them is a perfectly normal thing to build.
Starting from a template
Rather than tick every box from scratch, click Seed from Template in the role form and pick a template (you can search, or filter by Industry). The template fills the grid with a starting set of permissions, which you then adjust. The role records which template it came from.
Templates are a starting point, not a fixed role — once seeded, the permissions are yours to change.
Company admins
Separately from company roles, every person has a company-level role — Admin, Member, or Auditor — chosen when they’re invited. Company admins have access across the company’s worksites — including worksites they were never explicitly added to, which is why they can appear on a worksite’s access list as implicit.
Worksite access
A company role says what someone can do. Worksite membership says where. A person is added to the worksites they need, and can hold different roles at different worksites.
Company Admins don’t need to be added to each worksite — they get every worksite implicitly. Everyone else needs a worksite row, with a role, for each worksite they should use.
Finding out what you can do
Permissions are enforced by the server, not just hidden in the interface. If an action isn’t available to you, your role doesn’t grant it — ask a company admin to adjust the role or assign you a different one.