HR Requests module
Your people raise requests through a form, not an email. Every request type has its own questionnaire, its own queue, its own deadline and a full trail. Nothing gets lost in an inbox.
An employment certificate requested by email has no number, no deadline and no history. Nobody knows whether anyone picked it up, the employee follows up, and the request goes back to the bottom of the pile. A service desk with no open door gets bypassed by email — and the request then leaves the system entirely, with no trail and no follow-up.
The employee picks a request type from a list. Internal queues — the ones one HR team uses to reach another — are never served to them, neither in the list nor by direct address.
Fields come from configuration, not from code: text, long text, date, month, dropdown. A field can appear only when another holds a given value, and a field can declare the request urgent.
Up to 5 files of 10 MB — PDF, images, Word, Excel, OpenDocument, text, CSV. They are stored in the employee’s documents, attached to the request, not in a corner of its own.
They see where each one stands and exchange messages with the HR team in the request thread. They cannot reach a colleague’s request, even by guessing its identifier.
When the type carries a deadline, the date is shown — and it is exactly the one the system watches to chase. No deadline configured means nothing is announced, rather than an empty promise.
Labels and descriptions are stored per locale, not in two fixed columns. A customer who turns on German or Italian translates their catalogue from the configuration screen.
By date, by status, or urgent-first. Sorting happens on the server: it covers the whole queue, not just the page on screen.
Two people cannot take the same request. The write is conditional, and whoever arrives second is told — they do not simply believe they won.
An internal note never reaches the requester: the filter sits in the query, not in the view. A message they receive is therefore, without exception, one meant for them.
Each type is addressed to a group, a team, a department or an office — the same picker onboarding already uses. With no destination, the request lands in the general queue.
These statuses describe processing. They are not an approval decision: a request can be in progress here and still awaiting approval there. Merging both into a single badge would make one of them lie.
First response: someone has picked up the file — the deadline that reassures. Resolution: the request is handled — the deadline that commits. Both are set in hours, per type, and either can be left empty.
Reconfiguring a type moves no date already announced. An employee promised Friday does not find out on Monday that it was Tuesday.
First response overdue: a reminder goes to the queue. Resolution overdue: an escalation goes to the designated owners. Each deadline carries its own marker, so nothing repeats.
While the ball is in their court, the HR team has nothing to answer for: no escalation goes out. That is exactly the kind of unfair alert that makes people stop reading them.
The module does not arrive empty. Four types cover the most common requests and act as templates — rename, deactivate or extend them, with no code release.
Addressed to (optional), additional details. A certificate is usually generic: making the recipient mandatory forced employees to invent an answer just to submit.
Period concerned and question, both required. A line on the payslip looks wrong or unclear.
Document requested, plus an urgency level that genuinely moves the request to the front of the queue — not a decorative checkbox.
Subject and details. The open door, so nobody has to bend a neighbouring type or fall back on email.
The internal-queue example: one HR team asking another, invisible from the employee portal.
“I have a question about my payslip” is not waiting for a decision, it is waiting for an answer. If you configure an approval chain for HR requests, submission opens it and the approval engine already in place — the one behind absences, expenses and desk bookings — carries it, with its delegation and its four-eyes rule. If you configure none, the request goes straight to the processing queue: that is the normal case, not an anomaly.
That journey already exists in the profile, with its own circuit. A second path would have created two queues and two truths about a governed field.
While waiting on the requester, the deadline keeps running. It triggers nothing, but it is not suspended.
Approve and Reject stay in your existing approval inbox. This module carries the processing, not the decision.
