Roles and permissions

Overview

RockOps checks two separate things before letting someone act, and mixing them up is the most common source of "why can't they see this" confusion.

Holding an organization role does not, by itself, give someone access to every project. Only Administrator, Owner, Finance & Accounts, and Store & Inventory Manager (for inventory only) can reach every project without being added to it. Every other project-facing role — including Project Manager — also needs a seat on that project's team before they can open it. Someone whose organization role is Project Manager but who hasn't been added to "Riverside Bridge" cannot see "Riverside Bridge" at all, even if they manage other projects just fine.

It also helps to know what to expect when a role doesn't have permission for something:

Both happen in RockOps. An Organization Manager, for example, can open People → Employees and see the Add Employee button, but submitting the form fails — only Administrator, Owner, and Human Resources can actually create an employee. The same thing happens with Add Team Member and Assign Contractor on a project's Team tab: anyone who can open the project sees both buttons, but only Administrator, Owner, and that project's own Project Manager can actually use them. Treat this page as the real answer, rather than what happens to be clickable on screen.

Organization roles

Fourteen roles exist. Thirteen are assignable through the System role field on an employee's Employment step. Owner is a special role that automatically belongs to whoever first set up your organization in RockOps — it can't be assigned to anyone else, and it never appears as a choice in the System role list. Administrator and Owner can do exactly the same things everywhere in this guide, with one exception: only Owner can delete the organization itself.

Organization-level permission matrix

People (HR)

"Full" means create, update, and activate/deactivate. Departments and Employees share the exact same rule — there is no role that can edit one but not the other.

Projects — access and scope

Projects — capabilities inside a project

The four roles in the last row can open a project they're staffed on and see its structural details (units, team, milestones), but none of them can see budget, accounts, work logs, inventory, or payment terms at all — that's deliberately narrower than Site Supervisor and Project Manager. Only Administrator and Owner can create, edit, or delete a project's payment obligations; Finance & Accounts and Project Manager can view them but not change them.

Procurement

PM Review and Admin Review are the two approval steps a purchase order can go through, shown as its status on the Procurement screen. PM Review is genuinely Project-Manager-only — Administrator and Owner do not act at that step themselves. When a purchase order reaches PM Review, only that project's own Project Manager can approve it; Administrator and Owner act at Admin Review instead, the same step Finance & Accounts uses. If the person raising a purchase order is the project's own Project Manager, PM Review is skipped automatically. At Admin Review, Finance & Accounts can approve up to a spending limit set for your organization — above that limit, only Administrator or Owner can approve. Nobody can approve a purchase order they raised themselves, at either step.

Contractors and payments

Site Supervisor is the one role here worth double-checking: it doesn't have its own Contractors page, but it can raise buy requests and log work against contractors on projects it's part of — those actions happen from inside the project itself, not from the Contractors section.

Materials and inventory

The one worth remembering: Store & Inventory Manager cannot create or edit catalogue items — that's Administrator/Project Manager's job — but it does have full inventory reach on every project, including ones it isn't staffed on. It's the same pattern as Finance & Accounts: wide visibility, narrow editing rights.

How project membership affects access

Everything in the tables above tells you whether a role is eligible for something across the organization. For project-related actions, there's a second requirement: an actual, active seat on that specific project's team.

Administrator, Owner, Finance & Accounts, and Store & Inventory Manager are the only roles that skip the team-seat requirement. For everyone else, being eligible at the organization level is necessary but not enough on its own. In practice: holding the organization role Project Manager makes someone eligible to manage projects, but they only actually manage the ones they've been added to. Being staffed as Project Engineer on one project gives no access at all to a different project, even though the organization role is identical on both.

Project team roles

A project's Team tab uses a separate set of nine roles, each with its own place in that project's reporting tree — distinct from, but linked to, the organization roles above. Each team role can only be given to an employee who already holds the matching organization role.

Procurement Coordinator and Store Coordinator are the two team roles with no identically named organization role — they're staffed from Procurement Officer and Store & Inventory Manager. The Project Manager seat isn't assigned from the Team tab at all: it's set when the project is created, and changed only through that project's own Change Manager action. See Staff a project for the full walkthrough.

Worked examples

• Priya holds the organization role Project Manager. She's staffed as Project Manager on "Greenfield Villas" but not on "Riverside Bridge". She has full manage, approve, budget, accounts, work-log, and inventory access on Greenfield Villas, and cannot see Riverside Bridge at all — not read-only, not partially, nothing — because she has no seat on that project's team, and Project Manager isn't one of the roles with automatic access to every project.

• Arun holds Finance & Accounts. He never appears on any project's Team tab, yet he can view budget, accounts, work logs, and payment terms on every project in the organization, and record contractor payments anywhere. Finance & Accounts is one of the roles with automatic access to every project, so it never needs to be staffed onto one.

• Fatima holds Site Supervisor and is staffed on "Coastal Warehouse". She can log site work, raise buy requests, and view work logs and inventory for that one project — but she cannot see its budget or accounts at all (Site Supervisor doesn't have that access on any project), and she has no reach into any other project.

• Deepak holds Organization Manager. He can see every department, employee, and project in the organization, but strictly on a read-only basis: he cannot create an employee, edit a department, approve a project, or view a single budget figure anywhere. It's a wide-visibility role, not an editing one — that's what sets it apart from Human Resources, which can edit people records but has no access to Projects, Procurement, or Contractors at all.

• Kavya holds Worker. She has no access to the main RockOps application at all — Worker doesn't appear in any of the access tables above. Workers do their day-to-day work through RockOps Site, a separate app on their phone, against whatever they're assigned there.

Best practices

• Grant the narrowest role that lets someone do their actual job. Organization Manager and Human Resources look similar but aren't interchangeable: Organization Manager is read-only oversight across departments, employees, and projects; Human Resources can edit people records but has no access to Projects, Procurement, or Contractors at all. Picking the wrong one either blocks real work or hands out more visibility than intended.
• An organization role alone doesn't put someone on a project. Granting Project Manager (or any project-facing role) on the Employment step makes a person eligible; they still need an actual team seat on each project, added from that project's Team tab. Forgetting this step is the most common cause of "they have the role but still can't see the project."
• Reserve Finance & Accounts and Store & Inventory Manager deliberately. Both are the only project-facing roles besides Administrator/Owner with access to every project — Finance & Accounts into every project's money, Store & Inventory Manager into every project's inventory ledger — with no team seat required. Handing either to someone who only needs one project's numbers grants far more than that.
• Don't expect Administrator to unblock the PM Review step of a purchase order. It's the one approval step that genuinely requires the Project Manager role and nothing else. Administrator and Owner act at the Admin Review step instead, the same one Finance & Accounts uses.
• Pair the organization role with the team role on purpose. The Add Team Member picker only offers employees whose organization role already matches the team role you're assigning (Project Engineer to Project Engineer, Store Coordinator to Store & Inventory Manager, and so on) — decide both at once rather than granting a System role and figuring out the team role later.
• Only grant a System role when the person actually needs to sign in to RockOps. It creates a login account immediately, tied to their personal email, and still needs a separate "Send invitation" step afterward — see Add an employee.
• Don't treat a visible button as permission. Creating an employee as Organization Manager, or adding a team member as someone other than that project's own Project Manager, both show the button and let you fill in the form — then get refused when you submit. Check this page, not what's clickable on screen, before assuming a role can do something.

See also