Skip to main content

Subproject Roles

Subproject roles are the second layer of the access model. Where the org role is a user's organization-wide baseline, a subproject role grants additional, scoped permissions inside one specific subproject. They are how you give someone extra authority on a particular project phase without changing their organization-wide role.

Subproject roles govern what a user can do within an assigned subproject; the org role governs everything else and acts as the baseline.

There are 3 subproject roles, each scoped to the subproject it is assigned to.

The three subproject roles​

Sales Head (subproject)​

Subproject-scoped sales execution and supervision. Within the assigned subproject the user can create and edit quotations and sales-order / sales-invoice drafts, and supervise that subproject's sales work. No approvals or cancellations.

Sales Staff (subproject)​

Subproject-scoped, execution-only sales. Within the assigned subproject the user creates and edits the drafts assigned to them. The narrowest sales role.

Project Manager (subproject)​

Subproject-scoped operational execution. Within the assigned subproject the user creates and edits units, maintains unit readiness, and uploads SVG layouts. No sales authority.

Subproject roleWhat it adds within the subproject
Sales HeadCreate/edit quotations and SO/SI drafts; supervise subproject sales
Sales StaffCreate/edit assigned sales drafts
Project ManagerCreate/edit units, maintain readiness, upload SVG layouts

They are additive and scoped​

Two properties define how subproject roles behave:

  • Additive — a subproject role only ever adds permissions on top of the user's org role. It can never remove or restrict something the org role already allows.
  • Scoped — the added permissions apply only inside the subproject the role is assigned to. The same user, acting on a different subproject where they have no subproject role, falls back to their org role alone.

A user can hold several subproject roles at once — for example, Sales Head on one subproject and Project Manager on another.

How the override works in practice​

Worked example. Priya's org role is Sales Staff (frontline drafting, project-scoped). She is given the Sales Head (subproject) role on Subproject A.

  • On Subproject A, her permissions are her Sales Staff baseline plus the subproject Sales Head additions — so she can supervise and progress sales drafts there.
  • On Subproject B, where she has no subproject role, only her Sales Staff org role applies.
  • For org-wide actions (such as banking or partnerships), only her org role applies — the subproject role is irrelevant.

Assigning a subproject role to a user​

Subproject roles are assigned per user, per subproject:

  1. Open the user in the Users area.
  2. Go to their subproject role assignments.
  3. Choose the subproject role (Sales Head, Sales Staff, or Project Manager) and the subproject it applies to.
  4. Save. The user immediately gains that role's permissions within that subproject.

You can assign multiple subproject roles to the same user, each tied to its own subproject. To remove one, delete that specific assignment — the user keeps every other role and their org-role baseline.

:::note Who can assign subproject roles Assigning subproject roles is a role-management action, available to the Admin role and to roles holding the subproject role-assignment permission. See the RBAC matrix. :::

When to use a subproject role vs. an org role​

  • Use a subproject role when someone needs extra authority on one project phase but their organization-wide standing should not change.
  • Use an org role change when someone's responsibilities shift across the whole organization.

For example, a Sales Staff member temporarily leading a launch is a perfect fit for a subproject Sales Head role on that launch's subproject — no need to promote their org role.