A Saudi holding company running five to fifty legal entities faces a governance question that mainstream HRIS platforms were never designed to answer: how do you let an HR Manager in Company A see her own employees, attendances, and payslips — while preventing her from touching the same records in Company B, Company C, or the group consolidation view? The default answer from Western HR tools is to either share one admin account across the group (a NDMO audit failure waiting to happen) or to purchase a separate tenant per entity (a cost and reporting nightmare). U HR's answer is different: a granular role-based access control (RBAC) engine built around five manager-app features — Modules, Permissions & Roles, HR Accounts, Classification Lists, and Projects & Teams — that lets a Group Head of HR scope every administrator to the right slice of the organization without ever leaving a single connected system.
The multi-company RBAC problem in Saudi holdings #
Most HRIS platforms sold into the Kingdom were built for a single-employer model: one legal entity, one admin role, one set of permissions applied uniformly to every HR user. That model collapses the moment a holding company acquires its second subsidiary. The Group Head of HR suddenly needs an HR Business Partner who supports Company A's construction arm to see attendances for sites in Makkah and Riyadh — but not the salary structures of Company B's professional-services consultants. The HR Director of Company C needs full create, edit, delete, and fetch rights on Classification Lists and Skill Catalog entries for her entity, but should not be able to alter the Level Definitions that the group has standardized across all five companies. Western HRIS vendors typically solve this by selling a separate tenant per legal entity, which breaks Nitaqat consolidation, doubles the licence bill, and forces the CHRO to email five HR managers every quarter to assemble a group-wide headcount. Mainstream HRIS platforms that try to retrofit multi-entity RBAC usually end up with one of two failure modes: either every HR user sees everything (a Saudi Labour Law data-privacy exposure), or no HR user sees enough to do their job (a productivity collapse that pushes the team back to spreadsheets).
Five U HR features working together #
U HR's manager application exposes five features that together compose a complete RBAC layer for multi-entity holdings: Modules registers every screen in the system as an addressable access-control object; Permissions & Roles lets the Group Head of HR grant create, edit, delete, and fetch rights per module per role; HR Accounts manages the administrator accounts themselves and the roles attached to them; Classification Lists standardizes the named pick-lists (request types, competencies, skill categories) that permissions reference; and Projects & Teams organizes work across project, team, and workspace scopes so that an HR Business Partner can be scoped to a single project site without ever touching the legal-entity boundaries. None of these features was visible on the original U HR landing page — they are part of the 19 newly-discovered features in the deep feature inventory — and together they answer the governance question that single-entity HRIS platforms simply cannot.
Modules: registering every screen for access control #
Modules is the foundation of U HR's RBAC engine because it turns every screen in the system — Organizations, Companies, Departments, Level Definitions, Position Catalog, Skill Catalog, Approval Management, Bulk Uploads, and so on — into an addressable object that Permissions & Roles can grant or deny rights to. Without a registered module layer, an HRIS can only offer coarse-grained role templates ('Admin', 'Manager', 'Employee') that inevitably grant too much or too little. By registering each screen explicitly, U HR lets the Group Head of HR compose custom roles such as 'Company A HR Manager — Attendance and Self-Service Requests only' or 'Group Compensation Analyst — read-only Payslips and Earnings & Deduction Rules across all companies'. This is the same pattern that enterprise HCM platforms use at the foundation-object level, but U HR exposes it to mid-market Saudi employers without the eighteen-month implementation cycle a Western HCM rollout typically demands. The result is that the same person who configures Position Catalog entries can also be the person who configures module visibility, because the access-control vocabulary is the same vocabulary the HR team uses every day.
Permissions & Roles: CRUD rights per module per role #
Permissions & Roles is where the access policy actually lives. For every role the group defines — HR Manager, HR Business Partner, Compensation Analyst, HR Director, Group Head of HR — the system records four independent rights against every module in the catalog: create, edit, delete, and fetch. That CRUD granularity matters because most HR governance failures are not 'the wrong person saw the wrong screen' but 'the right person did the wrong action on the right screen'. An HR Business Partner who legitimately needs to view Employee Profile records for her department should never have delete rights on the same records; a Compensation Analyst who needs to read Working & Finance Info across entities should never be able to edit Earnings & Deduction Rules. Permissions & Roles enforces this distinction at the data layer, not the UI layer, which means an administrator who finds a back-door URL to a screen still cannot perform an action the role does not grant. For NDMO auditors, this is exactly the access-control evidence they ask for: not a marketing slide that says 'role-based access', but a per-role, per-module matrix that proves who can do what to which object.
HR Accounts: scoping administrators to entities #
HR Accounts is the third leg of the RBAC tripod: it manages the administrator accounts themselves and binds each one to a role and — critically — to a scope. A Saudi holding with three companies and twelve departments will typically provision a dozen HR Accounts: one HR Manager account per company (scoped to that company's employees, attendances, and payslips), three HR Business Partner accounts per company (each scoped to a department cluster), one Group Head of HR account (scoped group-wide with read-only access to compensation data), and one IT administrator account (scoped to Modules and Permissions & Roles configuration only, with no access to employee records). Because HR Accounts is a first-class manager-app object rather than a hidden IT setting, the Group Head of HR can reassign scopes in minutes when the org chart changes — without raising a ticket with Ukkera support or waiting for an external consultant. For NDMO compliance, the same HR Accounts records produce the administrator-access audit trail that an auditor expects: who was granted what scope, by whom, on what date, and when it was revoked.
Real-world scenario: a 3-company, 12-department holding #
Consider a Saudi holding that owns a construction company in Riyadh, a facilities-management company in Jeddah, and a professional-services consultancy in Dammam — twelve departments in total, 1,800 employees, and a single CHRO who reports to the board. In a mainstream HRIS, the CHRO would be forced to choose between one admin account shared across all three companies (a governance failure) or three separate tenants with no group-wide view (a reporting failure). In U HR, the same holding models all three legal entities under one Organizations → Companies → Departments hierarchy, then provisions exactly the right RBAC profile for every HR user. The HR Manager in Riyadh gets full CRUD on Attendance, Self-Service Requests, and Employee Profile for her company only — she cannot see the Dammam consultancy's payslips even by accident. The HR Business Partner supporting the Jeddah facilities-management sites gets CRUD on Attendance Oversight and Skill Approvals for two specific departments, scoped via Projects & Teams to the Jeddah site workspaces. The Group Head of HR gets read-only access to People Analytics and Skills & Calibration across all three companies, plus CRUD on Level Definitions and Position Catalog at the group level (because career frameworks are standardized group-wide). The CHRO gets a single dashboard view of the entire group, with the ability to drill into Approval Workflows for any entity but no ability to alter an individual employee record — exactly the separation of duties that Saudi Labour Law data-privacy articles imply and that NDMO auditors look for.
Implementation steps for multi-company RBAC #
Governance benefits #
The governance benefits of this RBAC design extend well beyond access control itself. First, NDMO compliance becomes a documentation exercise rather than a scrambling exercise — the role matrix that Permissions & Roles produces is exactly the evidence an auditor wants, with no separate spreadsheet to maintain. Second, GOSI and WPS submissions become more reliable because the HR Manager who certifies a payroll run is the same HR Manager whose HR Account is scoped to that company's payslips, eliminating the cross-entity data leakage that often produces rejected Mudad SIF files. Third, the CHRO's quarterly people report stops being a five-email chase — People Analytics and Org-Wide Visibility pull consolidated headcount, attendance, and skills data directly from the same permissioned records, because every HR Account in the group is writing to one shared data model. Fourth, the holding becomes audit-ready for procurement: when a NEOM or Aramco frame-agreement asks for evidence of HR access controls, the Group Head of HR can export the role matrix in minutes. Finally, the holding becomes resilient to insider threat: a disgruntled HR Business Partner in Company A simply cannot exfiltrate Company B's compensation data, because the data layer refuses the fetch. That is the kind of governance story that turns HR technology from a cost center into a board-level assurance.