RBAC is where CAFM security meets operational reality. Done well, it invisibly enforces segregation of duties and keeps sensitive data restricted. Done badly, it either locks people out of doing their jobs or gives everyone access to everything. Here is the model that works.
Standard user groups
Technician (TECH)
Executes WOs, updates status, records findings. No approval rights.
Supervisor (SUP)
Assigns WOs, creates PRs, validates completion. First-level control.
FM Engineer (ENG)
Approves WRs and PRs, validates technical scope, closes WOs.
Store Keeper (STORE)
Receives materials, creates GRNs, manages stock.
Procurement (PROC)
Manages RFQs, creates POs, coordinates with vendors.
Finance (FIN)
PO approval, budget control, payment processing.
Helpdesk (HDO)
Logs service requests, converts to WOs, monitors status.
System Admin
User provisioning, master data, configuration. Governance role.
RBAC design principles
- Role-restricted data. Users see and modify only data relevant to their role.
- Segregation of duties. Whoever creates a PR cannot approve it. Whoever receives goods cannot issue payment.
- Approval thresholds match authority. Don't give Supervisors PO approval above their signing authority.
- Sensitive data restricted. Financial data visible to Finance and Accounts only.
- All actions audited. User + action + timestamp captured for every transaction.
Data visibility in multi-org environments
Data visibility is not just about role
In multi-site CAFM, role alone isn't enough. A Supervisor at Site A should have Supervisor rights at Site A only, not at Site B. RBAC has to combine role (what) with organisation (where). See Multi-Site CAFM Architecture for the data-visibility model.
User provisioning
- Users created/managed by authorised administrators only.
- Each user assigned a role, organisation, department, and access level at creation.
- Accounts activated, suspended, or deactivated as needed (lifecycle management).
- Leavers deactivated promptly, ideally same day.
- Access reviews conducted periodically (quarterly at minimum).
Security controls
- Secure authentication (ideally SSO with corporate identity)
- Password policy enforcement (complexity, rotation, history)
- Session timeout for inactivity
- Account lockout after repeated failed login attempts
- Optional: MFA for administrative roles
Common RBAC design mistakes
- Too many roles. 40+ roles with subtle differences are impossible to manage.
- Permission creep. Temporary permissions granted "just for this week" that become permanent.
- Admin role for everyone. Shortcut that breaks segregation of duties entirely.
- No leaver process. Terminated employees with active accounts months later.
- No access review cadence. Permissions never re-examined. Drift accumulates.
Conclusion
RBAC is a discipline, not a feature. Design a small, well-scoped set of roles, enforce segregation of duties, combine role with organisation in multi-site setups, and review access periodically. The goal isn't maximum restriction, it's right-sized access that lets people do their jobs while enforcing the controls auditors need.
Written by Muhammad Abbas
Enterprise integration specialist designing RBAC frameworks for CAFM, EAM, and ERP systems.
