Canonical system roles
Use the current Owner, internal, Viewer, Client and Field Worker role catalogue.
Roles and permissions
Give each person the access their work requires.
Use NIYAM’s canonical workspace roles, site assignments and client boundaries so internal teams and external stakeholders do not receive the same navigation or server access.
The shared-access problem
One workspace should not mean one level of access.
Owners, supervisors, accountants, field workers and clients have different responsibilities. A hidden menu alone is not enough when the server record also needs protection.
A clear path from capture to responsible action.
Each step keeps the record, its context and the next responsibility visible.
- 01
Invite the person
Use the canonical invitation and membership workflow.
- 02
Choose the operating role
Select the supported role that best matches the person’s responsibility.
- 03
Assign site or client context
Add the existing site assignment or client scope where required.
- 04
Enforce every request
Keep navigation, protected routes and server actions inside the canonical permission contract.
What roles and permissions covers.
Focused capabilities for the complete workflow, described within their supported operating boundaries.
Permission-aware navigation
Show supported work surfaces according to the current role experience.
Server enforcement
Retain authenticated API permission checks beyond visible navigation.
Site and client scope
Keep field work assignment-scoped and client views explicitly shared.
Visible access model
The current product exposes the canonical role catalogue and a smaller client experience.
Approved evidence shows read-only system roles and the client-safe Project, Reports and Messages view. Product truth also records route and API enforcement for supported workflows.
- Canonical role catalogue
- Permission-aware routes
- Assignment- and share-scoped client access
A useful record has a responsible next person.
The feature supports the handoff without blurring who records, reviews or receives the information.
Owner or Admin
Invite people, choose supported roles and keep access understandable.
Internal team
See the operational work allowed by role and site context.
Viewer or Client
Review intended information without internal mutation or administration controls.
Access boundary
Roles support least-necessary access; they are not a certification claim.
NIYAM’s current RBAC, tenant and assignment controls govern supported product workflows. The page does not claim custom-role building, regulatory certification or enterprise readiness from RBAC alone.
- No custom-role-builder claim
- No certification claim
- Tenant and server checks remain authoritative
Questions about roles and permissions.
Straight answers about scope, review and responsibility.
Can Owners create custom roles?
The current public proof covers NIYAM’s canonical read-only system role catalogue. Custom-role creation is not claimed on this page.
Does hiding a menu protect the API?
No. NIYAM’s supported access contract also includes authenticated route and server permission enforcement.
What can a Client see?
Assigned clients receive the smaller Project, Reports and Messages experience and only explicitly shared information.