Approvals

Luna HR routes requests to the right people for approval. Leave requests, expense reports, and training requests all go through an approval workflow before being actioned.

How approvals work

When an employee submits a request, Luna HR determines who needs to approve it based on:

The employee's line manager — the default approver for most requests
The org structure — managers of the employee's department or team
Workflow rules — configurable approval chains for more complex scenarios

The approval flow

For most requests, the flow is straightforward:

Employee submits a request (leave, expense report, training)
The request routes to their line manager
The manager approves or declines from the Approvals page
The employee is notified of the decision

Multi-level approvals (Expenses)

Expense reports can have additional approval steps:

Manager approval — the employee's line manager reviews
Finance authorisation — for higher-value claims, a second sign-off from finance
Payment — finance marks the report as paid

The authorisation step is optional and configured via Policies.

The Approvals page

All pending items are consolidated in one place:

Go to Approvals from the sidebar
Switch between tabs: Leave, Expenses, Training
Review each request — see the details, check team coverage (for leave), and view attached documents
Approve or Decline with an optional comment

The approvals page also shows:

Authorisations — expense reports awaiting finance sign-off
Payments — approved expenses ready to be marked as paid

Each of the three tabs has two views: Pending, the requests waiting on you, and a second view of what you have already actioned — called Decided for Leave and Training, and Actioned for Expenses.

Once you action a request it leaves the Pending list, so the second view is where you go to check what you agreed to, re-read a reason you gave, or confirm whether you already dealt with something. Each view lists your 25 most recent with a Show more button, and shows decisions you made rather than your whole team's history.

Note: Expenses and Training only began recording who decided each item when this view was added, so anything actioned before then is not listed. The decider is still shown on the item itself — a claim's Approval History card names who approved, authorised and paid it.

Leave

Expand a row to see the employee's note, your decline reason, and the dates.

A request you approved that the employee later cancelled still appears, marked Approved · later cancelled — the fact that you agreed to it is part of the record, and hiding it would make your history disagree with the calendar.

Leave auto-approved by policy is not listed, since nobody ruled on it.

Expenses

A claim passes through approve → authorise → pay, and one person can act at more than one stage. Actioned lists a claim once for each stage you handled, labelled with what you did — so a claim you approved and later paid appears twice, because those were two separate things you did.

A claim you sent back for revision shows as Returned. Its own status goes back to draft so the employee can revise it, which is why the label comes from what you did rather than from where the claim is now.

In a multi-step approval chain, only the person who took the final decision sees the claim here. Earlier steps remain on the claim's own Approval History.

Training

Expand a row to see the completion date, the cost, and the reason you gave if you returned the request. Training auto-approved by policy never appears.

Bulk actions

For busy periods, you can select multiple requests and approve or decline them in bulk.

Actor resolution

Luna HR uses several strategies to find the right approver:

| Strategy | How it works | |----------|------------| | Line manager | The employee's direct manager (set on their profile) | | Node manager | The person with the "manager" role on the employee's org node | | Ancestor manager | Walks up the org tree until a manager is found | | Role-based | Routes to anyone with a specific permission (e.g. expenses:approve) |

These strategies are used by Luna HR's workflow system and can be configured for different scenarios.

Approver preview

Before submitting a leave or expense request, employees see exactly who will approve it. The preview appears on the submission form and shows:

The approver's name — so the employee knows who to expect a decision from
"HR admin" — if no line manager or org tree manager was found and the request falls back to an HR admin
"Automatically approved" — if the policy means no approval is required (e.g. auto-approve rules)
Delegation info — if the usual approver has an active delegation, the preview shows the delegate's name with a note like "delegated from Sarah Jones"

This removes the guesswork from submitting requests and gives employees confidence that their request will reach the right person.

HR admin fallback

When Luna HR cannot find a suitable approver through the normal resolution chain (line manager, node manager, ancestor manager), the request is routed to an HR admin instead.

This prevents requests from being silently auto-approved when an employee has no line manager set or the org tree has gaps. The fallback works as follows:

Luna HR attempts to resolve an approver using the configured workflow steps
If no approver is found, it looks for any employee with the admin permission
If an HR admin is found, the request routes to them — the employee sees "HR admin" in the approver preview
If no admin can be found at all, submission is blocked with a clear error message asking the employee to contact their HR team

This safety net ensures that every request gets a human review.

Custom approval chains

Beyond the default single-step manager approval, you can build multi-step chains under Admin > Approval Workflows. Each step has a name, an approver (using the strategies in the table above), and optionally a condition and an escalation.

The page has a tab for each module that runs approvals — Expenses, Leave and Training — and shows the tabs your company actually has. A chain belongs to exactly one module: an expense chain never applies to a leave request, and a chain cannot be moved between modules, because the requests already in flight refer to it.

Only one chain applies to a request. Luna HR picks the one scoped to the requester's org node — the most specific match, walking up the tree — and falls back to the company-wide default if there is no scoped match. With neither, the module's single-approver default applies.

Preview a request before you commit to a chain

Under the table, Preview a request answers the question the builder cannot answer on its own: who would actually be asked to approve this? Pick a requester and describe a sample request, and Luna HR resolves the chain the same way it would on submission — the same template lookup, the same conditions, the same actor resolution — rather than reading the template back to you.

The preview is explicit about two things it cannot promise:

A step routed to a fallback approver (nobody matched the configured actor, so it went to an admin) is chosen per request. A real request may land on a different eligible person, and the preview says so on that step.
Leave policy can be set per leave type. The no-template preview resolves module-level policy only, so a leave type carrying its own approver override is not reflected there.

Conditions

A condition decides whether a step is required for a particular request. Add one to a step and it only runs when the condition holds — for example, a Finance step that applies only above £1,000.

The fields on offer depend on the module, because the same request does not vary in the same ways:

| Module | Field | Compared as | Operators | |--------|-------|-------------|-----------| | Expenses | Amount | Number — the report total | > >= < <= = | | Expenses | Item count | Number — how many items are on the report | > >= < <= = | | Expenses | Currency | Text — the report's currency | = only | | Leave | Duration | Number — length of the request in days (half days count as 0.5) | > >= < <= = | | Training | Course cost | Number — 0 when the course has no cost recorded | > >= < <= = | | Training | Currency | Text — the currency the cost was entered in | = only |

Leave deliberately offers one field. A leave request has no item count and no currency of its own, so a control for either would look meaningful and could only ever hold the duration again, or the literal "days".

All conditions on a step must hold for it to run.

If Luna HR cannot evaluate a condition, the step still runs. A condition referring to something the system doesn't recognise keeps the approval rather than dropping it, so the worst outcome is an approval you didn't strictly need — never a report that skips a sign-off it should have had.

Auto-approve conditions

Separately, a step can carry auto-approve conditions — when those hold, the step passes without anyone acting on it. This also fails safe: if the condition can't be evaluated, the step goes to a person instead of auto-approving.

If every step in a chain is skipped or auto-approved, the request is approved on submission with no human review. Take care when putting a condition on the first step of a chain — that is the case where a request can pass straight through. The preview shows this as "No step needs a human".

Editing a chain that is in use

Steps cannot be changed while requests are part-way through that chain, for the same reason the template can't be deleted — the running approvals refer to the step numbers. Rename the template, change its description or its org scope freely; to change the steps, wait for the in-flight requests to finish or cancel them.

Escalation

A step can escalate after a set number of hours without a decision. When it does:

The request moves to a different approver — never back to the person who let it time out, and never to anyone who already approved an earlier step
The new approver is notified that a request has become theirs, marked high priority — in Luna and by the same "awaiting your approval" email the first approver gets. The next approver in a multi-step chain is emailed the same way when an earlier step is approved
The requester is notified that their request was passed on, so a silent delay doesn't look like being ignored

If no eligible approver can be found, the step stays where it is rather than routing back to someone who has already acted on it.

Approval trail

Luna HR records who acted on each request and displays this information for transparency:

Leave requests — the activity timeline shows who approved or rejected the request, with their name and the date
Expense reports — a dedicated Approval History card shows every step in the chain: submitted by X > approved by Y > authorised by Z > paid by W, with names, dates, and timestamps
Delegation badges — if any step was handled by a delegate, the trail shows the delegate's name alongside a "delegated from [original approver]" badge

The approval trail is visible to the requesting employee, the approvers, and admins.

Approval chain — where a request is right now

Every request also carries an Approval chain view: each step of its workflow in order, with who acted (or is waiting), when, and why it was them. A step that is waiting shows how long it has been waiting and since when; a step handled by a delegate shows who they were standing in for; a step that timed out and escalated stays in the record alongside the person it was passed to. Steps the chain has not reached yet read as Not yet reached.

You will find it:

On a leave request under View activity in your requests list
On an expense report's Approval History card, when the chain has more than one step
On the Approvals page, in the expanded detail of any pending or decided row

It is visible to the requester, everyone on the chain (including the person a delegate acted for), and admins.

On my behalf

If someone covers your approvals through a delegation period, the On my behalf tab on the Approvals page lists every leave, expense and training request they decided in your name — who decided it, what they decided, and the reason they gave. Your delegate's own Decided view marks the same rows with "for [your name]", so both sides can see that the decision was made under delegated authority.

The tab lists final decisions. Where a delegate handled one step of a longer chain and someone else took the final call, that step appears on the request's own Approval chain rather than here.

Payments ledger

Anyone who can mark expenses as paid (admins and the expenses:pay permission) has a Payments view under Approvals > Expenses: every claim paid in a date window, whoever paid it, with the method and payment reference recorded at the time, plus who approved and authorised it. Totals per currency and per method cover the whole window, not just the rows on screen, and the list exports to CSV for bank reconciliation. It defaults to the current month.

Approval Monitor (admins)

Admin > Approval Monitor lists every request in the company that is still waiting for a decision, oldest first, with:

Who has it — the current approver, and who they are covering for if they are a delegate
How long — the age of the current step, flagged Overdue once it passes the step's escalation window (or 72 hours where the step has no escalation configured)
What has escalated — the escalation count, and a marker when a step has hit the escalation cap and is waiting for a person to resolve it
By approver — how many requests each person is holding and how many are overdue

Expand a row to see the full chain, or use Remind to send the current approver a high-priority in-app notification naming the request and how long it has waited, with an optional note. It is a notification inside Luna, not an email. A reminder can be sent once an hour per step and is recorded in the activity log.

You cannot remind yourself, and a step that is no longer waiting on anyone cannot be reminded. The list covers the 500 longest-waiting chains and says so when there are more.

A row marked Stale belongs to a request that is no longer pending (it was decided or withdrawn outside the workflow) — it can be ignored.

Approval Speed report (admins)

Reports > Approval Speed measures how long requests waited for a decision, from submission to the final decision, over a date window (the last 90 days by default). It shows the overall median, 90th percentile and the share decided within 24 and 48 hours; the same figures per module; a table per approver, slowest median first; and the twenty slowest individual decisions. Both tables export to CSV and PDF.

Per-approver figures are attributed to the final decider, so in a multi-step chain the last approver carries the whole wait — that is the delay the requester experienced. The split between steps is on the request's own Approval chain. Requests approved automatically by policy are not counted, since nobody decided them.

Delegation periods

Going on holiday? Delegate your approval responsibilities so requests don't pile up while you're away.

Setting up a delegation

Go to Delegation under Company Structure in the sidebar (Admin > Delegation Periods opens the same page)
Click Add Delegation
Select the delegator — the approver whose requests need covering
Select the delegate — the person who will handle them
Choose the kind of cover:
- Temporary — a start and end date, for a specific absence
- Standing (no end date) — a permanent backup, set to activate only when on leave (the default) or always
Tick the modules it covers — Leave, Expenses, or both
Optionally cap the maximum approval value the delegate may sign off, and leave "Delegate cannot approve their own requests" ticked
Save

While the cover is live, leave and expense requests that would normally route to the delegator are sent to the delegate instead. When it ends, routing reverts on its own.

The delegate is told in Luna and by email (the Delegation Created template) whenever cover is handed to them — a new delegation, a standing backup, or an existing period switched to a different delegate. The email follows their Delegation & backup toggle on the Notifications page. A standing "when on leave" backup says that it only applies while the manager is on leave. Nobody who has left or is suspended is told.

Admins can set up a delegation for anyone. Anyone who approves requests can set one up for themselves without admin rights — that is what the "Delegate approvals" offer does when you book leave.

Luna refuses a delegation where the delegator and the delegate are the same person, where the end date falls before the start date, or where it would form a loop (A delegating to B while B already delegates back to A over the same modules and dates).

Who is covering whom today

A saved delegation is not always diverting approvals: a temporary one waits for its start date, a standing "when on leave" backup only bites while the manager is on approved leave, and a delegate who is themselves away is skipped. The Cover today panel at the top of Delegation shows each live period with its real state — Covering now, On standby, Starts later or Delegate unavailable — using the same rules the routing engine applies.

Both people in a delegation also see it on the Approvals page: the delegate is reminded that they are covering for someone (and for which modules, until when), and the person being covered can see that their queue is currently going elsewhere.

How it works

Delegations cover leave and expenses, picked per delegation. Training approvals are not delegated — training runs its own approval flow, so a training request always stays with its usual approver.
Routing is decided when a request is submitted. While cover is live the request is assigned to the delegate and appears in their Approvals page; it does not also sit in the delegator's queue.
Because of that, cancelling or deleting a delegation does not pull back requests already routed to the delegate — those stay with them.
A delegate is never handed their own request, and with "Delegate cannot approve their own requests" ticked they cannot use delegated authority on anything of their own.
Delegation can chain: if the delegate has a delegation of their own in force, the request moves along it. A later hop never carries more authority than the first — the original maximum approval value applies to the whole chain.
If nobody in the chain is available, the request stays with the original approver rather than being auto-approved, and waits for them to return.
Delegations, and every decision taken under one, are recorded in the activity log.
Multiple delegation periods can be set up in advance (e.g. for planned holidays throughout the year).

Departing employee reassignment

When marking an employee as inactive or a leaver, Luna HR checks whether they have approval responsibilities. If they do, a reassignment dialog appears listing:

Direct reports — employees who have the departing person as their line manager
Policy overrides — any policy sets where they are the designated approver
Node roles — org nodes where they hold a manager or lead role
Active delegations — any delegation periods where they are the delegate
Pending approvals — requests currently awaiting their decision

You can bulk reassign direct reports to a new manager directly from the dialog. Policy overrides and node roles link to the relevant Company Structure pages for manual update. Active delegations are flagged for cancellation.

This ensures no approval responsibilities are left orphaned when someone leaves.

Leave — leave approval flow
Expenses — multi-level expense approval
Training — training request approval
Roles & Permissions — permissions that affect approval routing