Speed up decisions. End the waiting.

One engine, not a setting inside every module

Every module in any HR system needs approvals: leave, advances, overtime, penalties, rewards, assignments, transfers, resignations. The architectural question determining the whole system's quality is not "are there approvals?" but "where are they defined?"

When each module carries its own configuration it feels flexible and becomes chaos. Organisational changes do not happen in one module: a manager leaves and what they approve — across leave, advances, penalties, assignments — must move to someone else. In a scattered design that means editing eight places, one of which will be forgotten.

So approval cycles are defined in one list governing the whole system: who approves each request type, in how many steps, with what conditions and delegation. An edit happens once in one place and applies to every request of that type.

The request stuck on an approver who left

This is the most common and least visible failure in HR systems. No error message, no alert — the request simply does not move, the employee assumes someone is considering it, and it surfaces only when they complain two weeks later.

There are two layers to the answer. First, the route derives from the org structure so it moves automatically with any transfer or reporting change — rather than a manual list that goes stale within months, carrying names that left and missing names that arrived.

Second, delegation: who stands in while a manager travels, falls ill or takes leave. Without it one of two things happens — requests stall and work stops, or the manager's credentials are handed to someone else. The second voids the whole meaning of approval, because the record will say the manager approved when they did not. The difference shows a year later when someone asks: who approved this?

How many steps does an approval deserve?

Every extra level adds real delay and adds protection only if the second approver holds information the first does not. A level that always approves because it does not know what it is approving is not control but latency.

So the step count is configurable per type: a leave request may pass one level — the direct manager is the only person who knows whether the employee can be away those days — while a penalty or an advance passes two. The level of control matches the decision's impact rather than being uniform.

The overlooked case: no cycle defined

What happens to a request of a type with no approval cycle defined? The answer should be known in advance rather than discovered later — because it means either the request takes effect immediately with no approval, or it never takes effect at all.

The behaviour in Nova HR is defined and stated: if no cycle is defined for the employee, the request becomes effective immediately. That makes the absence of a definition a conscious choice: if you want a request without approval, define no cycle; if you want approval, define one.

A team assuming every request passes an approval while one type takes effect immediately is working on a false premise — usually discovered after something has taken effect that nobody decided.

The approval is not the validation

A common confusion: leaving the manager to discover for themselves that the employee's balance is short or the date falls in a peak season. That turns approval into data checking rather than a management decision.

Sound design separates them: validation happens at submission, so what breaks the rules is refused before reaching anyone — insufficient balance, an overlap, a blackout day, exceeding a monthly cap, or more than half the department being away in the same window.

The manager then receives a valid request, and their decision rests on what only they know: can this person be spared those days? That is the question approval exists for.

What makes an approval auditable

An approval whose author and time are unknown is not an approval but an event. In any later review — a labour dispute, an internal audit, a question about an old decision — the first question is: who decided?

So every request carries its trail: who raised it and when, who reviewed it, who approved it. Completed by the operations log recording who did what and when across the system. Its value is not catching bad faith — that is rare — but explaining an error in minutes rather than a days-long investigation.

It has a quieter preventive effect too: a known log changes behaviour before anyone reads it. An edit its author would not want attributed to them simply does not happen.