HR Accounts is the administrator-management screen inside U HR Manager. It is where the Group Head of HR provisions every HR user, binds each one to a role from Permissions & Roles, and — critically — scopes each one to a slice of the organization. The screen looks unremarkable: a list of administrator accounts with their assigned roles and scopes, plus a create-new-account form. That unremarkable appearance hides the fact that HR Accounts is the single most important governance object in the entire U HR platform, because it is the only place where the abstract access-control policy defined in Permissions & Roles meets the concrete reality of named human administrators. Every NDMO audit and every MHRSD review eventually asks the same question: who, exactly, has administrative access to your HR system, what can they do, and when did they get that access? HR Accounts is the screen that answers that question natively, without a side spreadsheet or a manual export.
What an HR Account actually is #
An HR Account is not the same as an employee record. Every employee in U HR has an Employee Record — the personal data, the job assignment, the level, the position, the payslip history — managed through the Employee Records feature in the organisation view. An HR Account is a separate object: the credentials and the access policy that let a specific person log into U HR Manager or Employee Manager and perform administrative actions. Most employees do not have an HR Account — they access U HR Employee through their employee credentials, which give them self-service scope only. A subset of employees (HR Managers, HR Business Partners, HR Directors, Compensation Analysts, the Group Head of HR) have an HR Account on top of their Employee Record, and the HR Account is what determines what they can do in the manager applications. The separation matters because it allows the same person to be both an employee (with their own self-service view) and an administrator (with scoped access to other employees' data), without those two roles bleeding into each other. The HR Account is also the unit of revocation — when an HR Manager leaves the company, the HR Account is deactivated, but the Employee Record stays intact for historical and audit purposes.
How scoping works in practice #
An HR Account binding has three components: the role (from Permissions & Roles), the entity scope (which company or department the administrator can act on), and the workspace scope (an optional Projects & Teams filter that narrows the administrator's view to specific projects, teams, or sites). The three components work together: the role determines what actions the administrator can perform; the entity scope determines which employees, attendances, and payslips they can see; and the workspace scope narrows the entity scope further when needed. A typical Saudi holding with three companies and twelve departments will 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). The scoping is enforced at the data layer, not the UI layer — an administrator who finds a back-door URL to a screen outside their scope still cannot see the data, because the underlying query is filtered by the scope binding before the page renders.
Why data-layer enforcement matters for NDMO #
A common pattern in HRIS platforms that retrofit role-based access is UI-layer enforcement: the role determines what menu items appear, but the underlying data API is unscoped — anyone with a valid session token can query any record by ID. That pattern fails NDMO audits because the auditor can demonstrate the data leak with a simple script. U HR enforces scope at the data layer: every query against employee data is filtered by the calling user's scope binding before the database returns results. This means an HR Manager scoped to Company A cannot retrieve a Company B employee's payslip by tampering with a URL parameter or by calling the API directly — the database simply does not return the record. The same enforcement applies to export and reporting: an administrator scoped to a department cluster cannot export a list of employees outside that cluster, because the export query is scoped at the data layer before it runs. This is the level of enforcement NDMO auditors look for, and it is what allows a Saudi holding to confidently answer «yes» when the auditor asks whether the HR system enforces need-to-know access.
The audit trail HR Accounts produces #
Every action taken through an HR Account is logged with the account identity, the timestamp, the action type, and the affected record. When an HR Manager opens an employee's Working & Finance Info, the access is logged. When a Compensation Analyst runs a Payslips export, the export is logged. When an HR Director approves a Level Progression Plan through Approval Workflows, the approval is logged. When the Group Head of HR reassigns an HR Account's scope, the scope change is logged — including who made the change, when, and what the previous scope was. The audit trail is queryable from HR Accounts itself: the NDMO auditor can ask «show me every action taken by HR Account X between dates Y and Z» and the system returns the list in seconds. This is the kind of evidence that turns an HRIS from a tool into a compliance asset — and it is what allows a Saudi holding to demonstrate, on demand, that the access-control policy documented in Permissions & Roles is actually enforced in practice.
A practical scenario: provisioning a new HR Business Partner #
A Saudi holding acquires a new subsidiary and needs to provision an HR Business Partner for the Jeddah facilities-management site. The Group Head of HR opens HR Accounts, clicks «New Account», and fills in three pieces of information: the person's identity (drawn from Employee Records, so the binding is to a real employee rather than a free-text name), the role (the «HR Business Partner — Field Sites» role previously configured in Permissions & Roles, which grants CRUD on Attendance, Self-Service Requests, and Skill Approvals but read-only on Payslips and Working & Finance Info), and the scope (Company B — Jeddah facilities-management — Projects & Teams filter: «Jeddah site»). The account is provisioned in seconds, the new HR Business Partner receives their credentials, and their access is live. Three months later, when the HR Business Partner moves to support the Dammam consultancy as well, the Group Head of HR opens the same HR Account, adds the Dammam company and the «Dammam site» workspace to the scope, and saves. The change is logged with the previous scope, the new scope, and the Group Head of HR's identity. Six months later, when the HR Business Partner leaves the company, the Group Head of HR deactivates the HR Account — the credentials stop working immediately, but the audit trail of every action the HR Business Partner took during their tenure is preserved for the regulatory retention period. This entire workflow happens inside U HR Manager, without an IT ticket, without a support request, and without a consultant.