Modules is the configuration layer of U HR — the screen where every application module and screen in the system is registered as an addressable object that HR can enable, disable, or expose to specific roles. It looks like a directory listing, and on the surface it is one: a flat catalogue of every screen the system ships with, from Organizations and Companies through Employee Profile, Self-Service Requests, Attendance, Working & Finance Info, Levels, Level Progression Plans, Skills, Skill Mastery, Skill Approvals, Positions & Career, Earnings & Deduction Rules, Payslips, Personal Workspace, Notifications, Departments, Level Definitions, Position Catalog, Skill Catalog, Bulk Skill Import, Approval Management, Modules, Permissions & Roles, HR Accounts, Bulk Uploads, Classification Lists, Projects & Teams, Org-Wide Visibility, Attendance Oversight, Employee Records, Level Management, Skills & Calibration, Approval Workflows, Career Progression, Scope & Workspaces, and People Analytics. That catalogue is the foundation of U HR's access-control model — without it, the Permissions & Roles engine would have nothing to grant rights against.
Why a registered module layer matters #
Most HRIS platforms offer access control through pre-baked role templates — Admin, Manager, Employee — that map to fixed sets of screens. That approach works for an English-first, single-entity SMB with a simple org chart, but it breaks down for a Saudi holding with five companies, twelve departments, and an HR team that needs to compose custom roles like «Company A HR Manager — Attendance and Self-Service Requests only» or «Group Compensation Analyst — read-only Payslips and Earnings & Deduction Rules across all companies». The Modules layer is what makes those custom roles possible. By registering every screen as a discrete object, U HR lets the Group Head of HR grant or deny create, edit, delete, and fetch rights against any combination of screens, composing roles that match the actual organisational structure rather than forcing the structure to fit a fixed role template. The same layer supports entity-level enablement: a holding can disable Payslips for a subsidiary that runs an outsourced payroll, or disable Position Catalog for an acquired company whose career framework has not yet been migrated.
How Modules feeds the Permissions & Roles engine #
Modules and Permissions & Roles are a pair: Modules owns the catalogue of what exists, Permissions & Roles owns the policy of who can do what to it. When the Group Head of HR opens Permissions & Roles to create a new role — say, «Attendance Specialist — Company A only» — the screen presents the full Modules catalogue as checkboxes, organised by feature family (employee self-service, manager application, organisation view). For each module, the role configuration offers four toggles: create, edit, delete, and fetch. The Group Head ticks the modules the role needs — Attendance, Attendance Oversight, and Self-Service Requests — and sets the appropriate rights for each (full CRUD on Attendance and Self-Service Requests, read-only on Attendance Oversight). When the role is saved, the policy is live immediately: any HR Account assigned to that role sees only the modules the role grants, with only the actions the role permits. The integration is bidirectional — when Ukkera releases a new module in a future version, it appears in the Modules catalogue automatically, and the Group Head can decide whether to expose it to existing roles or keep it disabled until the team is ready to adopt it.
Entity-level enablement without code #
A common Saudi holding scenario is the partial rollout: the parent company adopts U HR for the full feature set, but an acquired subsidiary comes in with a narrower scope — perhaps their payroll is still outsourced for six months, or their career framework has not yet been migrated from the legacy system. The Modules layer handles this without code. The Group Head of HR opens Modules, selects the subsidiary entity, and toggles off the modules that should not be visible to that entity's HR users — Payslips, Earnings & Deduction Rules, Position Catalog, Level Definitions, and so on. The subsidiary's HR users see a simplified U HR Manager with only the modules relevant to them, and the parent company's HR users continue to see the full set. When the subsidiary is ready to absorb the disabled modules, the Group Head toggles them back on — no migration, no re-implementation, no consultancy engagement. This is the kind of flexibility that Western HRIS platforms typically gate behind enterprise tiers or charge professional services for, and it is included in U HR by default because the underlying data model treats modules as first-class objects.
A practical scenario: three-company, multi-stage rollout #
Consider a Saudi holding that adopts U HR in three stages. Stage one is the parent company — a 600-staff construction firm in Riyadh that takes the full feature set on day one. Stage two is the Jeddah facilities-management subsidiary — 400 staff, going live six weeks later with everything except Payslips (still on the outsourced payroll for another quarter). Stage three is the Dammam professional-services consultancy — 200 staff, going live twelve weeks after stage one with everything except Position Catalog and Level Definitions (their career framework is being migrated from a legacy system and will land in month four). The Group Head of HR configures all three stages from the Modules screen without writing a single line of code or raising a single ticket with Ukkera support. The parent company's HR users see the full U HR Manager on day one. The Jeddah subsidiary's HR users see everything except Payslips and Earnings & Deduction Rules from week six. The Dammam consultancy's HR users see everything except Position Catalog and Level Definitions from week twelve. When each subsidiary is ready to absorb the disabled modules, the Group Head toggles them on — no migration, no re-implementation, no professional services engagement. This is the kind of staged rollout that mainstream HRIS platforms typically require a system integrator for, and U HR delivers it from the configuration UI.
Why this beats static SaaS configuration #
A static SaaS product treats configuration as a one-time event — you pick the modules you want at signup, and changing them later requires a contract amendment or a support ticket. That model works for a single-entity SMB with a stable scope, but it fails for a multi-entity holding whose scope evolves month by month as subsidiaries are acquired, integrated, and reorganised. U HR's Modules layer treats configuration as a continuous activity — the Group Head of HR can reconfigure module visibility any time, the change is live in seconds, and there is no contract amendment because the entire feature set is already in the tenant. This is the same model 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 the Position Catalog can also be the person who configures module visibility, because the access-control vocabulary is the same vocabulary the HR team uses every day.