Skip to main content

Decide leave and overtime requests

Leave and overtime are two queues of the same shape: an employee submits a request, it sits in Pending, and someone with the right permission approves or rejects it. The pages behave almost identically, with two differences worth knowing — overtime decisions can carry remarks, and overtime can be decided by payroll as well as by HR.

Both pages use the shared toolbar described in the HR Administrator overview.

Leave requests​

/leave-requests needs hr.leave.requests.view to open. Approving and rejecting are separate permissions: hr.leave.requests.approve and hr.leave.requests.reject. A role can hold one without the other, in which case only one of the two actions appears — that is a configuration choice, not a fault.

Four tabs with counts: All, Pending, Approved and Rejected.

Eight columns: Employee # (pinned left), Employee Name, Leave Type, Date Requested, Start Date, End Date, Status and Decided By.

Decide one request​

Approve and Reject appear only on rows still in Pending, and only for the permission you hold.

  1. Open the Pending tab.
  2. Choose View from the row's kebab menu, or double-click the row, to read the request in full: employee, leave type, when it was requested, the start and end dates, who decided it and when. The drawer is read-only.
  3. Close the drawer and choose Approve or Reject from the row menu.

The decision applies immediately. The row moves to the Approved or Rejected tab and the counts on every tab refresh.

Decide a batch​

Select the rows you want, then use Approve or Reject in the bulk bar that appears above the table. Only the buttons matching your permissions are shown.

Non-pending rows in the selection are ignored — an already-approved request is not re-decided. Each request is sent separately, so if some fail the ones that succeeded stay decided and the message tells you the rest did not.

Leave decisions carry no remarks. If you need to record a reason, do it outside the decision.

Overtime requests​

/overtime-requests appears in both the HR Management and Payroll groups in the sidebar, because either side of the business may own the decision. Opening it needs hr.overtime.requests.view or payroll.overtime.approve; deciding needs hr.overtime.requests.approve or payroll.overtime.approve.

Four tabs with counts: All, Pending, Approved and Rejected.

Seven columns: Employee # (pinned left), Employee Name, Date Requested, Overtime Date, Hours, Status and HR Remarks.

The CSV and PDF exports on this page are available only to people who can decide requests. If the Table menu looks shorter here than on other pages, that is why.

Decide one request​

  1. Open the Pending tab.
  2. Choose View, or double-click the row, to read the request in full.
  3. Choose Approve or Reject from the row's kebab menu.
  4. A dialog opens with an optional Remarks box. Write a reason if the decision needs one, then confirm.

Whatever you write lands in the HR Remarks column on the request, where the employee and anyone reviewing the queue later can read it. Leaving it blank is allowed.

Decide a batch​

  1. Select the pending rows.
  2. Choose Approve or Reject in the bulk bar.
  3. The dialog offers Remarks (optional, applied to all) — one note attached to every request in the batch. Confirm.

Only pending rows are carried into the dialog; anything else in the selection is dropped before the dialog opens. Use per-request decisions when the reasons differ, and the batch when they do not.

Where these decisions land​

Neither queue is paperwork. Overtime pays only if it was approved: the payroll engine looks for an approved request on that exact date and pays nothing for the extra hours if it does not find one. Leave balances decrement on approval, not on submission, and approved paid leave is what some holiday-pay rules check for.

Both are therefore inputs to the pay computation described in Business rules, and a queue left pending at cut-off becomes a payroll correction afterwards. Working both to empty before a pay period is generated is cheaper than fixing it after.

Activity history​

Both pages carry Activity History in the row menu, listing the recorded activity against that request. It is the record of who decided what, and when.