Leave Approval Rules

1How matching works #

• Inactive rules are ignored.
• Complex rules first , by Priority (lower first) then rule number: the first whose condition answers Yes wins. A condition that fails is skipped and reported, never fatal.
• Then the Simple rules : active rules whose leave type is blank or equals the request's type, and whose days band contains the requested days (Min inclusive, Max inclusive, Max 0 = open-ended) - ordered by Priority, then typed beats any-type, then the NARROWER band, then the lower rule number.
• No match at all = the built-in default: one level, Reporting Person.
• A policy-based request matches by the policy's attendance type.
• The matched rule is stamped on the request - retiring a rule later never rewrites history.
• Matching normally happens once, at submit. The payroll setting "Re-check approval rules when an approver changes the request" (off by default) makes it happen again when an approver changes the type, policy, dates or days - see Writing a condition .

2Writing a condition #

A Simple rule is matched the way it always was: the leave type, and the number of days falling inside the Min/Max band. That covers most policies and needs nothing written.

A Complex rule ignores the type and the band and is matched by a condition instead — a Yes/No sentence about the request and the employee. Use it when the answer depends on several things at once ("more than five days AND in Production", "not enough balance left"), which no days band can express.

Which rule wins. Complex rules are tried first, in Priority order (lower number first, then the lower rule number); the first condition that answers Yes wins. Only if none does are the Simple rules considered, again by Priority, then the original most-specific ordering. So Priority is what decides between two rules that could both apply — give the exceptions the low numbers and the catch-all a high one.

A condition that will not read is skipped. Saving refuses a condition that does not parse, so it can not normally happen; but if one still fails while a request is being submitted (a value it needs is missing, say), that rule simply does not match, the request goes through on whichever rule does, and the submitter is shown a warning naming the rule. A leave request is never blocked by a broken condition.

Worked examples (var example in ConditionExamples) {

• }

Operators

• Compare — = <> < <= > >= ( == and != also work).
• Join — AND , OR , NOT (or && , || , ! ), with brackets for grouping.
• Arithmetic — + - * / % (remainder). A date minus a date gives days; a date plus a number moves it.
• Lists and ranges — Department IN ('Production', 'Stores') , Days BETWEEN 3 AND 5 , and NOT IN / NOT BETWEEN .
• Text match — LIKE with % for any run of characters and _ for one, as in EmpID LIKE 'PRD%' ; NOT LIKE for the opposite.
• Functions — UPPER , LOWER , LEN , ABS , ROUND(value, decimals) , YEAR , MONTH , DAY , TODAY() .
• Writing values — text in single quotes ( 'Production' ; a quote inside is doubled: 'it''s' ), dates between hashes ( #2026-04-01# ), Yes/No as true / false .
• Upper or lower case makes no difference — to the words, the variable names, or the text being compared: department = 'production' matches Production .
• Size limits — 1000 characters, 400 parts and 64 levels of nesting per condition. Split a longer one into two rules.

Variables you can use

Every field of the leave request and of the leave approval is available, in four groups:

• The request — everything the employee filled in (dates, days, type or policy, reason, contact details, reference numbers) and where the request stands (status, level, who entered it).
• The employee — name, code, department, designation, group, gender, joining date and length of service.
• The leave balance — available, accrued and used days on the policy that tracks this leave (all zero when no policy tracks it).
• Approval-time — the Approval… names: what an approver settled on. These exist only during an approval re-check (see below); while a request is being submitted they do not exist at all, so a condition using one can not be worked out and its rule is quietly skipped — never matched, never fatal, and the submitter is told which rule was skipped and why.

Nothing else may be named — an unknown name is refused on Save, with the position it sits at and the closest declared name as a suggestion. The same table (from the same list) sits under every Complex rule's condition box as Variables & operators , where clicking a name inserts it — this panel is the fuller explanation, that one is the quick crib.

Re-checking when an approver changes the request

An approver may change the leave type, the policy, the dates or the days before recommending or approving. The setting "Re-check approval rules when an approver changes the request" (Payroll Settings, Leave Request & Approval ) decides what happens next. It is off by default, and while it is off the rule matched at submit is simply the rule that applies — exactly as before.

Turned on , an action that changed any of those four re-matches the rules against the changed values, and only for that run the Approval… variables exist, carrying what the approver entered. If the rule that now matches needs more approval levels than the request already has, the action does not finalise: the request is escalated, waits at the next level, and an Escalate entry naming the rule and the reason is written to the trail so the extra level explains itself. No approval voucher, attendance posting or balance utilization is written by an escalation.

• ApprovalDays > Days — the approver granted more days than were asked for.
• ApprovalDays > 10 AND Days <= 10 — a short request that the approver turned into a long one.
• ApprovalLeaveType <> LeaveType — the approver changed the leave type.

Give such a rule two levels and a high-enough Priority and it becomes the "a bigger grant needs a second signature" rule. It can never affect a plain submission, because at submit there is no approver and no Approval… value to read.

3Approver kinds #

• Reporting Person - the employee's reporting person from the Employee master, shown as "waiting on" in the inbox. Because logins are not linked to employee records, ACTING still requires the approve permission. Setting 175 off degrades this kind to "any approver".
• Named user - a specific login; that user may act on the level without holding the approve permission.
• Any approver - every holder of the approve permission (Approve on the Leave Approvals object in the user manager).

4Your first rule, step by step #

Suppose leaves over 5 days need a second, HR-level approval.

1. Press Add Rule (F3) ; leave the type blank (any leave).
2. Min Days 5.01, Max Days 0 (open-ended) - up to 5 days stays with the default rule.
3. Levels 2; Level 1 = Reporting Person; Level 2 = Named user, pick the HR manager.
4. Describe it ("Long leave needs HR"), press Save (F5) .
5. Submit a 7-day request on the Leave Request page - the inbox now shows "level 1 of 2" and offers Recommend instead of Approve.

5Field details #

• Priority - the order rules are tried in, lowest number first; it is what settles two rules that could both apply. Ties fall back to the rule number.
• Kind - Simple matches on leave type and days band; Complex ignores both and matches on the condition written under the row. Switching to Complex greys those cells, and saving clears them.
• Condition (Complex only) - the Yes/No expression; see Writing a condition . Test… tries it against sample values without saving.
• Leave Type - blank matches every leave type (clear it with the x). Not used by a Complex rule.
• Min / Max Days - the requested-days band, inclusive; Max 0 = no upper bound. Not used by a Complex rule.
• Levels - 1 (approve directly) or 2 (recommend at level 1, approve at level 2).
• Level 1 / Level 2 Approver + User - the kind per level; the user cell applies to the Named-user kind only.
• Inactive - the rule stops matching new submissions; already-submitted requests keep it.
• Remove - deletes on Save; requests that used the rule keep their stamped copy of its outcome.

6Shortcut keys #

• F2 Reload · F3 Add a rule · F5 Save · Esc Discard unsaved changes.
• Enter moves to the next field.
• Keys belong to the focused copy of the page; a dialog's own keys win while it is open.

7Why is a pick-list empty? #

• Leave Type lists Attendance Types with Base Type Leave - maintained in the Attendance Type master.
• User lists the application's logins (the user manager) - not employee records.

8Rules and integrity #

• One transaction - adds, edits and removals of one Save commit or roll back together.
• Levels are 1 or 2 ; a two-level rule must name its level-2 kind; a Named-user level must name the user - refused otherwise, client and server alike.
• Band sanity - Max Days is 0 (open-ended) or at least Min Days; negatives are refused. Checked on Simple rules only - a Complex rule does not use the band.
• A Complex rule needs a condition , and that condition must read: the save parses it and refuses anything malformed or naming a variable that does not exist, quoting the position. Priority may not be negative.
• Keep one catch-all - the seeded default (any type, any days, 1 level) guarantees every request finds a rule; deleting it is allowed but leaves matching to the built-in fallback.