What "Employee Self-Service" actually means
The name is an industry term and it tells a newcomer almost nothing, so start with the plain version: ESS is the app an ordinary employee opens to deal with HR without going through HR. It is a tile on the platform's launcher, next to mail and chat, and everybody in the tenant has it — no role to request, no permission to be granted.
Inside, it does five things and only five. It shows how much leave you have left (رصيد الأجازات). It lets you raise a request and watch where it has got to. It shows your payslips once they are final. It lists your personnel documents and warns you when one is about to expire. And it shows your own employment facts. Everything it displays belongs to the one employee who is signed in — which is what separates it from the HR back office, where a clerk opens other people's files.
Why ESS is a second catalog tile, not a tab
Technically, ESS and the HR back office are the same frontend. The catalog simply publishes it twice: once at its root for HR staff, and once pointed at /me for everybody. Two tiles, one codebase. That looks like duplication until you look at who is allowed to open each one.
HR back office
Role-gated. It opens other people's pay, penalties, loans, insurance numbers and termination settlements. Only HR staff should be able to launch it, and most employees should never even see that it exists.
الموارد البشرية · Human ResourcesSelf-service
Public to every member of the tenant. It opens only the signed-in employee's own file. Gating it behind a role would mean an HR admin has to grant every new joiner permission to see their own payslip.
الخدمة الذاتية · Self-service · /meOne tile could not serve both. A single entry would force a choice between two bad options: gate it, and self-service disappears for the workforce it was built for; open it, and you have advertised an HR admin console to the entire company, with the whole back office hidden only by client-side checks. Hiding a menu in the browser is a courtesy to the user, not a security boundary — the URLs are still there, and anyone can type one. Publishing two tiles makes the boundary an entitlement, decided before the app ever loads.
The visible proof is in the two screenshots above and the ones in the HR field guide: the back office shows six administrative menus over an employee roster; ESS shows five possessive ones over a single file. Same build, different door, different contents.
Whose record is this? Ask the token, never the URL
Every ESS endpoint resolves the employee from the caller's access token. There is no employee id in the path, none in the query string, none in the request body — not as an optional parameter, not as a convenience for testing.
How it resolves
The signed-in user → their person record → their open employment period → that employee's data. Each hop is a server-side lookup. If the signed-in user has no open employment period, the app has nothing to show them, and that is the correct answer rather than an error to be worked around.
Why an id in the URL is fatal
Because /me/payslips/2026-06 and /payslips/2026-06?employee=1041 are not two spellings of the same thing. The second makes "my payslip" one edited digit away from a colleague's — and the only thing standing between them is a server-side check that somebody has to remember to write on every single endpoint, forever. Removing the parameter removes the class of bug.
The five screens
LV-2026-00004) so it can be quoted in a corridor conversation.
The request wizard — validate first, route second
Raising a request is three steps: 1. نوع الطلب pick the type · 2. التفاصيل fill in the details · 3. المراجعة review and submit. The interesting design decision is invisible in the screenshot: all validation happens before the request is routed to anybody.
What is checked before submission
| Check | Applies to | What it prevents |
|---|---|---|
| Sufficient balance | Leave | Requesting 10 days against a balance of 4 |
| No overlapping leave | Leave | Two approved absences covering the same day |
| Casual leave: max 2 days per occasion | Casual (عارضة) | Using casual leave as a holiday in two-day slices — art. 128 |
| Instalment within 25% of wage | Loan (سلفة) | Agreeing a repayment the law forbids deducting — art. 114 |
Why up front and not on approval: approving something the system must then refuse to execute is worse than refusing it at the door — by then the employee has been told yes. They have booked the flights, or spent the advance. A rejection at submission costs someone thirty seconds; a rejection after approval costs trust, and usually produces a manual override that puts the illegal deduction back in by hand. So the wizard refuses to submit what the engine could not apply.
Payslips appear only when the run is locked
A payroll run passes through calculation and review before it is locked. Until that moment, ESS shows the employee nothing for that month — not a draft, not a provisional figure, not a greyed-out preview.
Before the lock
The run is still being calculated. An attendance correction, a late loan instalment, a penalty entered a day later — any of these can still move the net. The number is not wrong; it is not yet a number.
After the lock
The figures are the record. The payslip is published with its full audit trace behind it, and any later correction has to appear as a visible adjustment in a subsequent run rather than as a quiet edit.
Showing an unlocked run starts an argument about a number nobody has approved. The employee sees 14,200, HR later corrects it to 13,850, and the conversation is now about why their pay was "cut" — a conversation caused entirely by publishing a working figure. Waiting for the lock costs a day of visibility and saves the entire discussion.
On a phone
ESS is the HR surface most likely to be opened on a phone — a leave request is typically raised from a sofa, not a desk — so the phone layout is not an afterthought.
Where the request goes next: ESS owns the form and the validation, but not the approval chain. What happens after إرسال — the stages, the manager's inbox, the send-back, and the moment the effect is actually applied to a balance or a payroll — is covered in HR Requests & Approvals.