Skip to main content
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

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.

​
The two-step chain

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

​
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 for the full scope model.

​
Where the queues live

Manager app → Approvals

One combined queue: leave, regularizations and overtime from your direct reports, with the context needed to decide.

Admin console

Per-surface queues — Leave requests, the Regularizations inbox, the swap board — plus bulk approval where it makes sense.

Employee app

Not a queue: where you file and track your own requests and see the stage each is at.

AI agents (MCP)

An agent acting as you can list your pending approvals and act on them, under exactly your permissions and scope.

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