Roles Overview

What you can see and do in Vruksha is decided by your role. This page explains the role system in plain language so you understand why your screen looks the way it does — and why a colleague's might look different.

Vruksha uses a two-layer role system: one organization-wide role that defines who you are, plus optional per-subproject roles that define what you can do inside a specific subproject.

Layer A: your Organization Role (exactly one)

Every user has exactly one Organization Role. It defines your identity across the whole organization and controls access to organization-wide actions — finance, HR, user management, master data, partnerships, and approvals. The eight standard organization roles are:

Role	In short
Admin	Full access to everything.
Partner	Read-only visibility into their own ownership.
Self-Managed Partner	A partner who also manages their own banking and finance details.
Finance Manager	Executes finance operations (but not approvals).
Sales Head	Runs sales and supervises the sales team.
Sales Staff	Frontline sales — creates draft quotations and sales orders.
Project Manager	Manages units and layouts (project execution).
People Manager	Handles employees and payroll (HR).

Your Organization Role is what the menu and buttons are filtered against. If you don't see a module, your org role doesn't grant it.

Layer B: Subproject Roles (zero or more, additive context)

On top of your org role, an administrator can assign you Subproject Roles — one per subproject you work in. These let you do subproject-specific work without giving you that authority everywhere. There are three standard subproject roles:

Subproject role	In short
Subproject Sales Head	Sales execution and supervision within one subproject — leads, quotations, SO/SI drafts. No approvals.
Subproject Sales Staff	Execution-only sales within one subproject — drafts assigned to them.
Subproject Project Manager	Unit and layout operations within one subproject. Cannot publish layouts or set final statuses.

You can hold different subproject roles in different subprojects — for example, Sales Head in "Sunrise Layout" and Sales Staff in "Moonlight Apartments".

How the two layers combine: the merge rule

This is the single most important rule to understand:

Your Organization Role is always your baseline. When you act inside a subproject where you also hold a Subproject Role, that subproject role's permissions are added on top — the two sets are combined. Everywhere else, only your Organization Role applies.

Subproject roles only ever add permissions — they never take any away. Your organization role is always your baseline; inside a subproject where you also hold a subproject role, your effective permissions are the union of the two.

In other words:

• Action targets a subproject + you have a subproject role there → your org-role permissions plus the subproject role's permissions both apply (whichever set grants the action wins).
• Action targets a subproject + you have no subproject role there → only your org role applies.
• Action is not subproject-specific (banks, partnerships, HR, audit, master data) → only your org role applies; subproject roles are irrelevant.

A quick example

Ravi's org role is Sales Staff. He's also been given Subproject Sales Head for "Sunrise Layout".

• Assign a lead in Sunrise Layout → his Sales Staff permissions plus Subproject Sales Head apply → allowed (the subproject role adds the "assign leads" permission).
• Assign a lead in Moonlight Apartments (no subproject role there) → only Sales Staff applies → denied (Sales Staff alone can't assign leads).
• Open Bank Accounts (not subproject-specific) → only Sales Staff applies → denied. His Sunrise Layout role doesn't help here.

Important: subproject roles are intentionally restrictive

Subproject roles are designed to scope work, not to elevate it. They deliberately leave out high-authority actions like approving, cancelling, overriding pricing, publishing layouts, and anything touching finance or ownership. Those remain organization-level authority (typically Admin). A subproject role never grants more than it explicitly lists, and it never "leaks" to another subproject.

A note on the menu vs. actual access

The left menu and on-screen buttons are filtered using your organization role — that's why the interface feels tailored to you. The real permission check still runs on every action, combining your organization role with any subproject role as described above. So the menu is a convenience; what you can actually do is what counts.

Where to learn more

• For the complete, permission-by-permission breakdown of every role, see the RBAC Matrix.
• Administrators who assign roles should read the relevant Admin Guides on users and roles.