Domain Roles & Capabilities

Define module-specific roles (Legal, Healthcare, Manufacturing…) and bind fine-grained capabilities to them — each add-on manages its own roles, while HR sees them all in one master matrix.

Roles vs. Capabilities

A Capability is a single, atomic permission written as domain:resource:action — for example legal:contract:approve or mom:floor:execute. A Role is a named bundle of capabilities (Senior Partner, Plant Manager). You bind capabilities to a role once; assigning that role to a person grants all of them at once.

Capabilities are not Skills

A capability decides what a person can do in the platform (a system permission). A skill (Python, Laparoscopy, Contract Law) is a personal competency managed by HR — it never affects access. Keep the two separate.

Decentralized, Domain-Tagged

Every add-on has its own Roles screen, but all roles live in one tenant-wide store. Each role is automatically tagged with the add-on's domain in the background — you never fill in a "type" field; the tag comes from the screen you're on.

Scoped capability picker

When a Legal manager builds a role, only Legal (and any global) capabilities appear. They can never see or grant another module's capabilities — a hard security boundary.

Approver capabilities

Some capabilities carry sign-off authority (e.g. Approve Contracts, Quality Inspect & Approve). A role that includes any of them is automatically flagged as an Approver role.

Out-of-the-box roles

The first time a domain's Roles screen is opened, sensible default roles are seeded so you can add staff immediately — no need to define a role by hand first.

Default Roles Shipped per Module

Module	Seeded roles
Legal	Senior Partner (Approver), Associate Lawyer, Paralegal
Manufacturing	Plant Manager (Approver), Production Supervisor, Quality Control Inspector (Approver), Machine Operator, Maintenance Technician
Construction	Project Manager (Approver), Site Supervisor, Foreman, Safety Officer (Approver)
Energy	Grid Operations Manager (Approver), Control Room Operator (Approver), Field Technician, Meter Reader
Agriculture	Farm Manager (Approver), Agronomist (Approver), Field Supervisor, Farm Worker
Education	Dean (Approver), Instructor, Registrar

Creating a Custom Role

Open the add-on's Roles screen (e.g. Legal → Roles).
Click Add Role and enter a name (e.g. "Trainee Lawyer") and optional description.
Tick the capabilities this role should grant — only this module's (and global) capabilities are shown.
Click Save. The role is stored with this module's domain tag and appears immediately — and in HR's master matrix.

Edit or delete a role from its row; deleting asks for inline confirmation.

The HR Master Matrix

Because HR is the single source of truth for the organization, HR → Organization → Roles & Permissions shows every module's roles in one table, tagged by domain, with a domain filter and a capability count per role. An HR administrator can review or override (edit/delete) any role — including ones created inside an add-on — while day-to-day authoring stays decentralized in each module.

Add-on manager creates role → Stored with domain tag → Appears in HR master matrix → HR can override

Frequently Asked Questions

Can a Legal manager grant Healthcare permissions?

No. Each add-on's capability picker is scoped to its own domain. No module can see or grant another module's capabilities.

Where are roles stored?

All roles across every domain live in one per-tenant store, each tagged with its domain. Add-on screens filter it by domain; HR reads the whole thing as a master matrix.

Do I have to define roles before adding staff?

No — each module seeds default roles on first open, so you can pick a ready-made role immediately when adding staff.