> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Attendance Requests & Check-In

> Two related tools sit alongside the daily attendance record. Employee check-in is the clock — the self-service in/out punches employees make from a phone…

Two related tools sit alongside the daily attendance record. **Employee check-in** is the clock — the self-service in/out punches employees make from a phone or browser, optionally stamped with their location, which roll up into attendance automatically. **Attendance requests** are the correction path — a formal ask to record or fix attendance over a range of dates (for example, "I was on a field visit Mon–Wed, please mark me Present" or "mark Thursday as Work From Home"), which an approver reviews before it touches the record.

This page covers both: how check-in works, how it becomes attendance, and how to raise and approve an attendance correction.

**You'll find this at:** check-in lives behind `hr/employee-checkins`; attendance requests behind `hr/attendance-requests`. The live check-in feed is shown on the [Attendance](/hr/user/attendance/attendance) page. See *Current state* for the UI gaps.

> Check-ins and attendance requests are **per business** and tied to the employee's **employment contract**. A multi-business employee clocks in against whichever business they have selected.

> 📷 *Screenshot: the clock-in / clock-out control with optional location capture — to be added.*

***

## Employee check-in (the clock)

A check-in is a single punch. Each one is either a **Clock in** or a **Clock out**, stamped with the time and optionally:

* **Location** — latitude, longitude, accuracy, and a human-readable place name.
* **Device** — which device made the punch.
* **Source** — *Mobile*, *Web*, or *Manual*.
* **Notes** — free text.

### Clocking in and out

* **Clock in** records a *Clock in*. You can't clock in twice — if you're already clocked in, Hitaji asks you to clock out first.
* **Clock out** records a *Clock out*. You can't clock out if you were never clocked in.

The [Attendance](/hr/user/attendance/attendance) page shows the day's punches live: who's *Currently in*, each person's first in and last out, and worked duration. A status lookup tells an individual whether they're currently clocked in and when they last punched.

### Manual and admin punches

An administrator can record a punch **on behalf of** an employee — choosing the user, the clock type, and even a past or future time — which is how missed punches and backfills are handled. Admin punches can be flagged to be ignored by auto-attendance when they're corrections that shouldn't re-derive a day. Admins can also delete individual or batches of check-ins.

### How check-ins become attendance

Punches don't become attendance on their own — they're rolled up by the shift engine:

* If the employee's [shift type](/hr/user/attendance/shifts) has **auto-attendance** turned on, an hourly job groups the day's punches against the shift, works out how long was worked, and writes a **Present** or **Half Day** attendance record (using the shift's hour thresholds). It stamps each processed punch with the shift it was attributed to.
* A daily job then backfills **Absent** for any working day that has punches expected but none recorded — unless a holiday or approved leave covers it.

Grace windows on the shift (how early a punch before the start still counts, how late after the end) and the business time zone all feed this calculation — see [Shifts](/hr/user/attendance/shifts).

***

## Attendance requests (corrections)

An attendance request asks for attendance to be **recorded or corrected** over a date range. It's how you fix a day the clock missed, record an off-site day, or mark work-from-home.

### What's on a request

| Field                   | Required            | Notes                                                                                         |
| ----------------------- | ------------------- | --------------------------------------------------------------------------------------------- |
| **From date / To date** | Yes                 | The range to correct. *To* cannot be before *From*.                                           |
| **Requested status**    | Yes                 | The status to apply to every day in the range — e.g. *Present*, *Work From Home*, *On Leave*. |
| **Half day**            | No                  | Marks one day in the range as a half-day.                                                     |
| **Half-day date**       | When half-day is on | Which day is the half-day; must fall inside the range.                                        |
| **Reason**              | No                  | Justification for the approver.                                                               |

### The request lifecycle

| Status        | Meaning                                                       |
| ------------- | ------------------------------------------------------------- |
| **Draft**     | Saved, not submitted.                                         |
| **Pending**   | Submitted and waiting for an approver.                        |
| **Approved**  | Cleared — attendance records have been written for the range. |
| **Rejected**  | Turned down.                                                  |
| **Cancelled** | Withdrawn before approval.                                    |

### What approval does

When a request is **approved**, Hitaji walks every day in the range and writes (or updates and locks) an attendance record for it — applying the requested status, and the half-day status to the nominated day. If a day already had an auto-generated **Absent** or **Holiday** record blocking the correction, that record is cancelled first so the approved status wins. The IDs of the records it creates are kept on the request as an audit trail.

If a request that was *already approved* is later **rejected**, Hitaji reverses itself — it cancels the attendance records it had written, so an erroneous approval can't quietly inflate someone's paid days. **Cancelling** is only allowed before approval; doing so also closes any open approval task.

### Separation of duties

Submitting a request and approving it are deliberately separate jobs. Raising or submitting a request needs `hr:write`; **approving or rejecting** needs the dedicated `hr-attendance:approve` permission. This stops someone from creating *and* clearing their own attendance corrections — important because attendance drives pay. Approval can run through the standard approval workflow, or an authorised approver can approve/reject a pending request directly.

***

## Permissions

| Action                                       | Permission              |
| -------------------------------------------- | ----------------------- |
| View check-ins / requests                    | `hr:read`               |
| Clock in / clock out (self)                  | `hr:write`              |
| Raise / submit / cancel a correction request | `hr:write`              |
| Approve or reject a correction request       | `hr-attendance:approve` |
| Manual/admin check-in, delete check-ins      | `hr:admin`              |

***

> ⚠️ **Current state.** The check-in and attendance-request engines are fully built on the backend — self clock-in/out, geolocation, auto-attendance roll-up, the correction workflow, and the separation-of-duties approval gate all work. The **web UI is partial**: the [Attendance](/hr/user/attendance/attendance) page *displays* the live clock-in feed, but there is currently **no dedicated screen** to raise or approve attendance correction requests, nor a built-in clock-in/clock-out button on these HR pages — those actions are driven through the API (or a mobile/self-service surface). (Flagged for the team.)

***

## Related

* [Attendance](/hr/user/attendance/attendance) — the daily record and the live clock-in feed
* [Shifts](/hr/user/attendance/shifts) — the shift settings that turn punches into attendance
* [Overtime](/hr/user/attendance/overtime) — extra hours derived from the same punches
* [Compensatory leave](/hr/user/leave/compensatory-leave) — uses attendance as proof of holiday work
* [Running payroll](/hr/user/payroll/running-payroll) — where attendance becomes payment days