هذا المحتوى غير متوفر بلغتك بعد.

Roles & Permissions

About Role-Based Access Control (RBAC) in UniCMMS

The Roles & Permissions module is the central security authority of the UniCMMS platform. It is designed so every user gets a workspace aligned with their job function while data integrity and security rules stay enforceable.

By applying a least privilege model, UniCMMS limits people to the data and tools they need for their tasks—reducing clutter for day-to-day work and lowering the risk of unauthorized changes to critical configuration.

Use this section to understand how roles work, how to define a role’s identity, and to browse the full permission catalog used when you edit a role in Admin Portal → Roles.

Add a role — new role, name, and permissions
Change a role — edit name, description, or permissions
Remove a role — only when no users are still on that role
Role identification — Name and Description on the role form
Permission reference — all functional sections and permission rows

Assigning a role to a user is done from Users; see How to add a user and How to update a user.

Key attributes and logic

1. The blank slate principle

Security in UniCMMS is off by default. When you add a new role, it starts with no permissions. An administrator must explicitly grant access to each module or action. That avoids permission creep, where accounts accidentally accumulate powerful rights over time.

2. Functional granularity

The product is organized into functional sections (see the permission reference). Within each section, rights typically fall into these patterns:

Operational rights — Add, edit, or view records for day-to-day work.
Administrative rights — Manage configuration, users, tenant rules, and similar controls.
Analytical rights — View insights, trends, and dashboards.
Data rights — Export data or manage technical attachments.

Exact labels vary by module; the reference lists each permission name as it appears in the UI.

3. Site-level scope and visibility

UniCMMS uses a centralized role assignment model: the same role applies everywhere the user is allowed to work. If someone is a Maintenance Manager, that role (and its permission set) is consistent across every site on their user profile.

Data isolation still applies by Active Site: after the user picks a site in the Site Switcher, lists and records (work orders, assets, inventory, and so on) filter to that location, without changing which role they have. See Site management for switching context.

Why this matters for your business

Enhanced security — Sensitive areas (for example purchase orders or asset depreciation) stay hidden unless a role explicitly allows them.
Operational clarity — Technicians can see a focused set of work-order and procedure tools; managers can see insights and dashboards without sharing admin keys broadly.
Accountability — Actions are attributable to signed-in users; pairing qualified roles with audit trails supports governance.
Scalability — You can add roles (for example Guest requestor or Regional auditor) as the organization grows, without rewriting existing workflows for everyone.