Skip to main content
A regularization is a request to correct an attendance record. It exists so that employees can fix a wrong day without being able to edit a wrong day — the change is claimed by one person and approved by another, and both are recorded.

​
The five kinds

Only a whole-day manual entry needs HR. The other four finish at the manager. This is deliberate: claiming an entire day from nothing is the one correction with no underlying punch to check against, so it gets a second pair of eyes.

​
Filing one

​
As an employee

1

Find the day

Open History in the employee app and go to the date. If the day looks wrong, the Request regularization action is there.
2

Say what should have happened

Choose the type, state the correction you are asking for — the time you actually arrived, the punch that is missing — and explain why.
3

Submit

It goes to your direct manager. You can follow its status and talk to the approver in the request’s discussion thread.

​
On someone’s behalf

Administrators and managers can file for an employee from the regularizations inbox (Mark on behalf). Pick the employee, the type, the date, the change and the reason. You can only do this for employees in your scope.

​
The approval chain

The HR step needs the hr:approve permission, and it cannot be the same person who approved at the manager step. Nobody can approve their own request. See How approvals work for the shared rules.

​
Deciding one

The detail page is built for deciding without leaving it.
Every real punch on the day, in order, with the proposed change shown alongside — so you can see what is being claimed against what actually registered.
The selfie from any punch that carried one, rendered inline. Coordinates and accuracy from any punch with GPS. Documents the employee uploaded on that date.
The location tile shows coordinates and accuracy, not a rendered map.
How many regularizations this employee has filed in the last 90 days, and the hours actually logged on the day in question. Occasional corrections are normal; a pattern is worth a conversation.
A thread between the employee, the manager and HR. Ask before rejecting — most regularizations are a genuine misunderstanding about what the record shows.
Approving or rejecting takes an optional note, which the employee sees along with the notification.

​
What approval does

Approving rewrites the day, inside the same transaction as the approval itself. There is no window where the request reads approved but the day still shows the old value.
If the day belongs to a frozen payroll month, approval is refused and the whole decision rolls back. Clear the queue before freezing a cycle.

​
The inbox

Attendance → Regularizations is the organization-wide queue. It carries:
  • Status filters — pending at manager, pending at HR, approved, rejected.
  • KPIs — how many are pending, the average time to resolve, and how many have aged past 48 hours.
  • Bulk approve — select several pending rows and advance them one step each. The result reports which were approved and which were skipped, and why.
  • Export — CSV of the current view, honouring the status filter.
The queue is scoped like every other approval surface: a manager sees their direct reports’ requests, an hr:approve holder sees the organization. Every row you can see is one you can open.

​
Aged requests

A regularization sitting for more than 48 hours is surfaced both in the inbox KPIs and on the admin dashboard’s alert feed. There is no automatic escalation or auto-approval — the alert exists so a person notices.