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

# The approvals queue

> One queue for leave, regularizations and overtime from your direct reports, with the context to decide each.

export const PermissionNote = ({perm}) => <Info>
    Requires the <code>{perm}</code> permission. Ask your administrator if an
    action described here is missing from your screen — see
    [Roles & permissions](/help/concepts/roles-and-permissions).
  </Info>;

The **Approvals** tab is a single queue holding three kinds of request. Filter pills narrow it: **All**, **Leave**, **Regularization**, **Overtime**, each with a count.

## What lands here

| Kind               | Permission               | What you are deciding                               |
| ------------------ | ------------------------ | --------------------------------------------------- |
| **Leave**          | `leave:approve`          | Whether someone can be away on those dates.         |
| **Regularization** | `regularization:approve` | Whether a claimed attendance correction is genuine. |
| **Overtime**       | `overtime:approve`       | Whether extra hours worked should be credited.      |

Only requests from your **direct reports** appear. Every row you can see is one you can open and act on — the queue is filtered by exactly the rule that guards the detail page, so you will never tap a row and be refused.

## Deciding with context

Open a request rather than swiping from the list when the decision is not obvious. Each kind carries its own context.

<AccordionGroup>
  <Accordion title="Leave" icon="palmtree">
    <PermissionNote perm="leave:approve" />

    * **Balance after** — what they would be left with, flagged if the request exceeds it.
    * **Team load** — how many others are already off on each day in the range, with a peak label. This is the coverage question.
    * **Backup** — who they nominated, plus suggested alternatives who are not themselves off.
    * **Prior pattern** — how much of this leave type they have taken this quarter.
    * **The approval chain** — whether HR reviews after you.
  </Accordion>

  <Accordion title="Regularization" icon="wrench">
    <PermissionNote perm="regularization:approve" />

    * **The punch trail** for the day, with the proposed change shown against what actually registered.
    * **Evidence** — the selfie from any punch that carried one, coordinates from any punch with GPS, and documents uploaded on that date.
    * **Pattern check** — how many regularizations they have filed in 90 days, and the hours actually logged.
    * **Discussion** — a thread with the employee. Ask before rejecting.
  </Accordion>

  <Accordion title="Overtime" icon="timer">
    <PermissionNote perm="overtime:approve" />

    The date, the minutes claimed, and their reason. The claim cannot exceed what the day actually earned, so you are deciding whether the hours were warranted, not whether the arithmetic is right.
  </Accordion>
</AccordionGroup>

## Approving and rejecting

Both take an optional note, which the employee sees with their notification. Write one on a rejection — you will be asked anyway.

Swiping a row acts on it directly: right to approve, left to reject.

### What you cannot do

<Warning>
  **You cannot approve your own request.** OnTime refuses it, whatever permissions you hold. If you file leave, it goes to *your* manager.

  **You cannot complete an HR step.** Some leave types, and whole-day manual regularization entries, need HR approval after yours. Your approval advances them; HR finishes them.
</Warning>

## What happens when you approve

Everything lands in one atomic step. For leave: the balance is debited and the covered days become `Leave`. For a regularization: the day is rewritten. For overtime: the approved minutes become an input to the day and, if the day was a holiday or rest day, comp-off is credited.

Then the employee is notified and an audit entry is written.

<Note>
  If a decision would rewrite a day inside a **frozen payroll month**, it is refused and rolls back entirely. You will see the refusal rather than a silent no-op. Payroll has locked that month — take it up with whoever runs it.
</Note>

If two approvers act at the same moment, exactly one wins and the other is told the request is no longer pending.

## Aged requests

A regularization sitting more than 48 hours is flagged both here and on the admin dashboard. Nothing escalates or auto-approves — the flag exists so a person acts.
