Vacation Rules Engine Examples: Accruals, Carryover, Blackout Dates, and Probation
Concrete rules-engine examples for accruals, carryover, blackout dates, and probation lockouts that an HR admin can configure on day one and live with year after year.
A leave policy that lives only in the handbook is a policy that gets enforced by whoever happens to read the request first. Two managers approving the same kind of request differently. A new hire booking five days during their first month because the probation rule is "understood, not configured". The carryover cap that worked last year but slipped during a December reorg. HR ends up enforcing rules by hand, which means HR ends up being the bottleneck.
A rules engine is the alternative. The policy is written once, configured in the tool, and applied automatically every time a request is submitted. This article walks through four concrete examples an HR admin can lift directly into BreezeLeave: accruals, carryover, blackout dates, and probation. Each example has the rule, the configuration, and the edge cases worth noting before you click save.
Example 1: monthly accrual with a seniority tier
The simplest accrual rule is "everyone gets 25 days a year, credited on January 1". The more common rule, especially for companies above 20 employees, is monthly accrual with a tier for tenure. A monthly schedule prevents mid-year hires from getting a full year's entitlement on day one, and a seniority tier signals to long-tenured employees that loyalty is rewarded.
A practical setup:
- 0 to 2 years of service: 25 days per year, accrued monthly at 2.083 days per month.
- 2 to 5 years of service: 27 days per year, accrued monthly at 2.25 days per month.
- 5+ years of service: 30 days per year, accrued monthly at 2.5 days per month.
In the rules engine, the seniority tier moves automatically when the employee's years-of-service threshold is crossed. The accrual rule should be configured to use the employee's hire date as the trigger.
Edge case
A new hire starting on January 15 with monthly accrual has accrued half a January when February 1 arrives. Decide upfront whether the first month is pro-rated or rounded. Pro-rating is more accurate; rounding is simpler to explain.
The detail on tier configuration lives in the seniority-based accruals article. It covers how the tier change is calculated and what happens at the transition month.
Example 2: capped carryover with Q1 expiry
Unused vacation at year-end is the single most-disputed item in HR's inbox in January. A useful rule is a capped carryover with an expiry date, which prevents balances from snowballing and gives employees a clear deadline to use leftover days.
A common configuration:
| Setting | Value | Effect |
|---|---|---|
| Carryover enabled | On | Unused days roll over to the new year |
| Max days carried | 5 | Anything above 5 is forfeited on January 1 |
| Expiry date | March 31 | Carried days expire if unused by end of Q1 |
| Applies to | Vacation only | Sick, personal, and emergency leave do not carry over |
The carryover rule applies at the year boundary. Carried days are tracked separately from the new year's accrual, so the system can expire them on March 31 while leaving the regular balance intact.
Legal note
In several EU countries, statutory vacation days cannot legally expire without the employer actively encouraging the employee to take them. The carryover cap is safest when it applies to days above the statutory minimum. Confirm with local counsel if you operate in countries where this matters.
The full configuration and year-end behaviour is in the vacation carry-over article and the carryover use case page.
Example 3: blackout dates for end-of-quarter and launches
A blackout date blocks new leave requests for a defined window. Useful examples are the last two weeks of each quarter for the finance team, a product launch week for engineering, or an audit window for the operations team.
Blackouts are usually team-specific, not company-wide. A finance blackout should not prevent the design team from taking time off. The rule should target the team or department that is affected.
- End-of-quarter: March 24 to April 4, finance and accounting only.
- Product launch: July 1 to July 14, engineering and product only.
- Audit window: November 1 to November 30, operations and HR only.
- Year-end shutdown: December 20 to January 2, all teams, with leave auto-deducted as the company-wide rule.
A useful detail: blackout dates should block new requests but should not invalidate already-approved requests. If someone booked a week off in March two months ago and the team adds an end-of-quarter blackout in February, the existing approval stays valid. The rule applies forward only.
For the full pattern, including how to communicate blackouts so employees do not try to book them, the blackout dates article and blackout dates use case page cover both sides.
Example 4: probation lockout for the first 90 days
Many companies restrict vacation requests during the probation period. The reason is usually operational: a new hire has not accrued meaningful days yet, and the team needs them in seat to ramp up. The lockout is easier to enforce as a rule than as a conversation.
A typical setup:
- Lockout period: 90 days from start date.
- What is blocked: vacation requests.
- What is allowed: sick days, personal leave, pre-approved exceptions recorded as adjustments.
- Exception path: HR can override the lockout for a specific request using a balance adjustment with a reason.
The 90-day window is common, but some industries use 180 days or align the lockout with statutory probation. The rule should match the contract language, not invent a new policy.
Edge case
A new hire with a pre-agreed honeymoon or family event during probation needs an exception. Record it as a balance adjustment with the agreed days and a comment; the audit trail then shows why the lockout was overridden.
The behaviour in BreezeLeave is described in the probation period lockouts article with the full setup screen.
Example 5: auto-approval for short, no-overlap requests
Not every request needs an approver. A two-day request, more than two weeks out, with no team overlap and no blackout conflict, is almost always going to be approved. Forcing the manager to click "approve" on it costs everyone time.
A useful auto-approval rule:
- Up to 3 working days.
- Submitted at least 14 days in advance.
- No other team member off the same days.
- Outside any active blackout window.
- Balance is sufficient.
Auto-approval is not "approve everything quickly". It is "approve the obvious cases automatically so the manager can spend judgment on the others". For longer requests, overlapping requests, or requests close to the start date, the normal approval chain applies.
The product flow is on the vacation rules engine page and the policy reasoning in the auto-approve vacation requests article.
How the rules interact
Rules do not run in isolation. A request hits accrual, balance, probation, blackout, overlap, and approval checks in sequence. Understanding the order prevents surprise rejections.
| Order | Check | If it fails |
|---|---|---|
| 1 | Balance sufficient for the request | Request blocked with insufficient balance message |
| 2 | Probation lockout applies | Request blocked, HR override available |
| 3 | Blackout date conflict | Request blocked, manager override possible |
| 4 | Auto-approval criteria met | Request auto-approved or routed for review |
| 5 | Approver receives notification | Approval, rejection, or request for changes |
The order matters because it determines the message the employee sees. A request blocked by balance shows a different error than one blocked by probation, which is different again from a blackout block. Clear messages prevent follow-up emails to HR.
Documenting the rules for the team
Once the rules are configured, write them down in one place. The employee handbook is the natural home, but the tool's settings screen should match. If the two disagree, employees will quote the version that gives them more days.
A short policy document with one paragraph per rule, the configured values, and the exception path is enough. Update it once a year when the rules are reviewed.
Putting it together
These five examples cover the policy decisions every HR admin makes in the first quarter of running a leave tool. Set them up once, document them, and the rules engine enforces them automatically for every request from that point on.
To build approval and accrual rules end-to-end, the vacation rules engine page walks through each rule type with screenshots of the configuration screens.
