> ## 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.

# How approvals work

> Who approves what, the two-step Manager to HR chain, the same-actor rule, and where each queue lives.

OnTime does not auto-approve. Every exception — time off, an attendance correction, extra hours, a shift swap — is decided by a person, and the decision is recorded with who made it and when.

All four request types run through the same decision machinery, so they behave consistently: the same refusal messages, the same audit trail, the same guarantees about what happens if two people click at once.

## Who approves what

| Request            | First step                     | Second step                                 | Notes                                                |
| ------------------ | ------------------------------ | ------------------------------------------- | ---------------------------------------------------- |
| **Leave**          | The requester's direct manager | HR — **only if the leave type requires it** | Configured per leave type.                           |
| **Regularization** | The requester's direct manager | HR — **only for a whole-day manual entry**  | The other correction types finish at the manager.    |
| **Overtime**       | The requester's direct manager | —                                           | Single step.                                         |
| **Shift swap**     | Depends on the swap rules      | —                                           | Some swaps auto-approve by rule; others need review. |

<Note>
  Whether leave needs an HR second step is a property of the **leave type**, not of the person or the number of days. Your administrator sets it when configuring the type.
</Note>

## The two-step chain

```mermaid theme={null}
stateDiagram-v2
  direction LR
  [*] --> AwaitingManager
  AwaitingManager --> Approved: manager approves<br/>(no HR step needed)
  AwaitingManager --> AwaitingHR: manager approves<br/>(HR step required)
  AwaitingHR --> Approved: HR approves
  AwaitingManager --> Rejected: manager rejects
  AwaitingHR --> Rejected: HR rejects
  Approved --> [*]
  Rejected --> [*]
```

Two rules govern the second step:

* **It needs a different key.** The HR step requires the `hr:approve` permission. A manager who does not hold it cannot complete the chain, and is told exactly that.
* **It cannot be the same person.** Whoever approved at the manager step is barred from also approving at the HR step. Someone holding both roles must hand the second step to a colleague.

## You cannot approve your own request

The same-actor rule applies at every stage. If you file a leave request and also hold `leave:approve`, OnTime refuses your own approval.

<Tip>
  **Rejection is deliberately different.** Nobody is barred from *rejecting*, including at the second step. A denial cannot defeat co-approval — refusing something does not need a second pair of eyes the way granting it does.
</Tip>

## Scope: whose requests reach you

Holding an approval permission is only half of it. You also have to be in scope for the person who filed:

* A **manager** sees requests from their **direct reports**. Not their reports' reports.
* A holder of **`hr:approve`** sees the whole organization — that key is precisely the override for the direct-manager restriction.

Queues are filtered by the same rule that guards the detail page, so every row in your queue is one you can actually open and act on. See [Roles & permissions](/help/concepts/roles-and-permissions) for the full scope model.

## Where the queues live

<CardGroup cols={2}>
  <Card title="Manager app → Approvals" icon="smartphone">
    One combined queue: leave, regularizations and overtime from your direct reports, with the context needed to decide.
  </Card>

  <Card title="Admin console" icon="monitor">
    Per-surface queues — Leave requests, the Regularizations inbox, the swap board — plus bulk approval where it makes sense.
  </Card>

  <Card title="Employee app" icon="user">
    Not a queue: where you *file* and track your own requests and see the stage each is at.
  </Card>

  <Card title="AI agents (MCP)" icon="bot">
    An agent acting as you can list your pending approvals and act on them, under exactly your permissions and scope.
  </Card>
</CardGroup>

## What happens when a decision lands

Approving is a single atomic step. In one transaction OnTime:

1. Moves the request to its next state — refusing if someone else already moved it.
2. Applies the consequence: the day record is rewritten, the leave balance debited, the roster cells swapped.
3. Commits.

Then, unconditionally, it notifies the requester and writes an audit entry.

<Warning>
  **If two approvers click at the same moment, exactly one wins.** The loser is told the request is no longer pending rather than silently double-applying the consequence. The same protection means a leave balance can never be debited twice for one request.
</Warning>

If the consequence fails — say a regularization would rewrite a day inside a frozen payroll month — the whole decision rolls back. You will not find a request marked approved whose effect never happened.