Skip to main content
Before you can do anything in HR you need to reach it, and you need the right permissions. What you can see and do depends on the role assigned to your login, and everything you do is scoped to the business currently selected in the switcher. This page explains how to open the HR area, what the six product areas are, and exactly which permission controls each kind of action — so that if a button is missing or a page says “no access”, you know why. You’ll find this at: /hr
📷 Screenshot: The HR Overview dashboard reached from the app launcher — to be added.

​
Reaching HR

Open the app launcher and choose HR Management, or go straight to /hr. This lands you on the HR Overview dashboard (HrDashboardPage), which shows:
  • Stat cards — Total Employees, Active, On Leave, and Org Units. Each is a link to the matching list.
  • Pending Leave Requests — leave awaiting approval (review them in Approvals).
  • Employees by Org Unit — distribution across your org units.
  • Recently Added employees and Today’s Attendance (clock-in/out counts).
  • Quick Actions — Add Employee, Add Document, New Leave, New Org Unit — plus shortcuts to the main HR pages.
⚠️ Current state: The “Employees by Org Unit” bars and the “positions” count on the Org Units card currently show 0 — the org-units list endpoint does not yet return per-unit employee counts or position counts (flagged in the code as TODO M2.13). The employee, leave and attendance figures are live. Treat the org-unit distribution as a placeholder until the backend surfaces those counts.

​
The six HR areas

In the app launcher, HR is grouped into six areas (these are the subcategory labels the launcher renders): The first five areas are admin/officer views. The sixth, Employee Self-Service, is for ordinary staff and is covered separately under The self-service portal.

​
How permissions work

Hitaji 360 uses permission slugs of the form area:action (for example hr:read). Your role is a bundle of these slugs. Each HR screen requires a slug to open, and each button requires a slug to act. If you lack the slug, the page or button is hidden (the navigation only shows tiles you can reach) or the server returns “forbidden”.

​
Admins bypass scope

There are two layers:
  1. Permission slugs decide what kinds of action you can perform.
  2. Business scope decides whose data you can touch.
A platform-level administrator — a true Admin, SuperAdmin or Super Admin role at the platform level — bypasses both: they can perform any action on any business’s data. Important nuance: a tenant-scoped admin role (one whose internal name carries a tenant suffix) does not get this bypass. So a normal “HR admin for this tenant” still works within scope; only the platform owner sees across everything. An ordinary HR officer is held to their slugs and to the business in the switcher.

​
The core HR slugs

Most of Core HR (employees, employment records, leave admin, grievances, separations, exit interviews) is gated by the legacy HR family:
Note: in the navigation, the Employees and Org Chart tiles are gated on hr:read / hr-employees:read, while the HR Documents tile uses hr-documents:read and the Template Centre and HR Reports tiles use hr-employees:read. The underlying employee/contract APIs all enforce the hr:read / hr:write / hr:admin family above.

​
Org structure slugs

The Org Structure screen has its own family, distinct from the employee slugs: → See Org Structure.

​
The other HR families

Each remaining area has its own slug family. The common pattern is :read to view, :write to change, :config to manage settings/templates, and :approve for approvals.
Some Leave & Attendance admin pages in the navigation are gated on the broad hr:read (e.g. Leave Requests, Leave Calendar, Staff Attendance), while the settings and allocation pages require hr-leave:config. Payroll’s setup pages (components, structures, periods, tax slabs, settings) require payroll:config; viewing payroll and reports needs payroll:read; approving a payroll run needs the separate payroll:approve (a deliberate separation of duties).
→ See Payroll overview for how the payroll slugs play out across running and approving payroll.

​
Employees get the self-service portal, not the admin screens

Ordinary staff are not given the HR-officer slugs above. Instead, once their employee record is linked to a login account, they reach the My HR portal at /my-hr. The portal’s tiles are gated on hr-leave:read, but the portal endpoints themselves are protected by a self-only guard: the server checks that the signed-in user is the same person as the employee record on every request, so a staff member can only ever see and change their own profile, payslips and leave — never anyone else’s, and with no admin back-door. Linking is done by an administrator from the employee profile (Link user / Invite user, which need hr:write or hr:admin). → See The self-service portal and The employee profile & its tabs.

​
Troubleshooting access

  • A whole HR area is missing from the launcher — your role lacks that area’s :read slug. Ask an administrator to grant it.
  • A page opens but an action button is missing — you have :read but not the :write / :config / :approve / :admin slug for that action.
  • “Employee not found” or a forbidden error opening a person — that employee has no contract in the business you’re in. Switch to the right business, or the person genuinely sits outside your reach (only platform admins see across businesses).
  • You changed business and the lists look wrong — they’re now scoped to the new business. That’s expected.