Picture a Friday afternoon in HR. A new hire submits a vacation request for the last week of the quarter. The policy says probation is 90 days, blackout dates protect the last two weeks of every quarter, and finance needs five business days of advance notice. You have to check three documents to confirm whether to approve. By Monday, you have eight more requests to review the same way.
That is the gap a vacation rules engine fills. The policy lives in one place, the system checks every request against it, and the cases that need human judgment are the only ones that reach an approver. Everything else gets a clear decision the moment it is submitted.
What the rules engine actually checks
BreezeLeave runs every leave request through a layered set of checks. Each check is configurable per company, and many are configurable per team or leave type. A request that fails any check gets rejected with the reason; a request that passes all of them either auto-approves or moves to the approval chain.
- Leave type and balance. Does the employee have enough days of the right type? Sick leave, vacation, personal days, and remote work each have their own balance.
- Advance notice. Was the request submitted with enough lead time? You set the minimum per leave type. Sick leave can be zero days, vacation can be five business days, sabbatical can be 60 days.
- Probation lockout. Is the employee within their probation window from the hire date? You set the duration and which leave types are blocked.
- Blackout dates. Does the request overlap a date range you have flagged as off-limits? Q4 retail, tax season for accounting firms, code freeze for engineering.
- Concurrent absence limits. Are too many people on the same team already out during those dates? The engine checks against approved leave on the team calendar.
- Auto-approval criteria. If the request matches your auto-approval rules, it skips human review and updates the balance immediately.
Auto-approval that is safe to turn on
Auto-approval is the part of the rules engine most HR admins are nervous about. The fear is that the system will rubber-stamp a long absence at the worst possible time. The fix is to make the criteria precise enough that auto-approval only fires on requests you would have approved anyway.
Useful criteria to combine:
- Leave type (sick leave is usually safe, vacation often is not).
- Duration cap (auto-approve up to 3 days, send anything longer to a manager).
- Time of year (auto-approve during low season, route everything else to a manager).
- Employee tenure (require manager review for anyone in their first six months).
- Team coverage check (auto-approve only if fewer than X teammates are already out).
A common starting point: auto-approve sick leave of three days or less for non-probation employees outside blackout windows. That handles most of the inbox and still leaves the judgment calls to managers. You can read policy examples from the rules engine for more starter configurations.
Pro tip
If a rule blocks a request, the employee sees the reason. Vague rejections are the fastest way to erode trust in an automated system. Write the rule names in plain language so the rejection message makes sense to the employee.
Seniority accruals without spreadsheet math
Tiered accruals are common in policies that reward tenure. A typical ladder grants 20 days in the first two years, 22 days from years three to five, and 25 days from year six. The problem is that the threshold dates land on different days for every employee, and someone has to update the balance when each person crosses one.
The rules engine handles this from the employee start date. You define the tiers once. When someone crosses a threshold mid-year, the engine prorates the additional days for the remainder of the accrual period. The balance updates on its own. If you want to see how this maps to common policies, the seniority-based accruals use case walks through three examples.
Carryover, caps, and expiry
Year-end is where leave tracking usually breaks. Some employees forget to use their days, some teams have a culture of carrying everything forward, and some countries have statutory rules that override the company policy. The carryover settings in the rules engine cover the common cases:
- No carryover. Use-it-or-lose-it. Unused days expire on the rollover date.
- Carryover with a cap. Move up to N days into the new year. Anything above the cap expires.
- Carryover with expiry. Move N days forward but set them to expire on a specific date (often March 31 or June 30).
- Country override. Run a stricter or more generous policy for employees in a specific country to match local statutory requirements.
The engine flags expiring days in advance so employees can plan, and it shows the carried balance separately from the new year accrual on the balance screen. The vacation carryover use case has the full setup walkthrough.
Blackout dates and probation lockouts
Two related rules cover most of the "this should have been blocked" cases:
Blackout dates
Date-range windows that block leave requests for everyone (or a specific team) within the range. Tax season for accounting, Q4 freeze for retail, launch weeks for a product team. You can attach a note that appears in the rejection message, which saves a lot of back-and-forth. See the blackout dates use case for example configurations.
Probation lockouts
A duration counted from the hire date during which certain leave types are blocked or capped. Many companies allow sick leave but block vacation for the first 90 days. The engine reads the employee start date and applies the rule automatically. New hires never have to ask whether they are eligible; the form tells them.
Approval chains for the cases that need review
When a request fails an auto-approval criterion (or you have not enabled auto-approval at all), the approval chain takes over. BreezeLeave supports:
- Single approver. The team lead reviews and decides.
- Sequential multi-step. First approver, then second, then third. Each step waits for the previous one.
- Simultaneous multi-person. All approvers see the request at the same time; voting policies decide the outcome (any one, majority, all must approve).
- Scoped approvers. On a mixed team, the dev lead can be scoped to approve only developers and the PM lead scoped to approve only PMs.
The configuration lives next to the rest of the policy in company settings. Read the multi-person approval page for the full feature set.
What it looks like in practice
A scenario. A 60-person company with offices in three countries runs the following rules:
- Seniority accruals: 20/22/25 days at 0/3/6 years for the US team, statutory minimums for the German and Spanish teams.
- Probation: 90 days from hire date, vacation blocked, sick leave allowed.
- Blackout dates: last two weeks of December for the US retail division, the first week of January for the EU finance team.
- Auto-approval: sick leave up to 3 days, any tenure, outside blackout windows.
- Manager approval: anything else, routed through the team lead, with a second approver for requests longer than 10 days.
- Carryover: 5 days, expiring March 31.
Once that configuration is saved, the HR admin spends time on policy decisions instead of request-by-request reviews. Managers only see the requests that need a real decision. Employees see balances and rejection reasons in plain language.
Where to start
Most HR admins do not need to enable every rule on day one. A reasonable order:
- Set the accrual and carryover rules so balances are correct.
- Add the probation window so new hires get a clear answer.
- Add blackout dates for the periods you already know are off-limits.
- Define the approval chain.
- Turn on auto-approval for the leave types where it is obviously safe.
- Review the rejected-request log after the first month and adjust.
For more starter configurations and policy templates, the PTO accrual rules examples post walks through five common setups.
Frequently asked questions
Everything you might want to know before getting started. Still have questions? Reach out anytime.
It applies your written policy at the moment a request is submitted. Accruals, carryover caps, advance notice, probation windows, blackout dates, approval chains, and auto-approval criteria all run as checks before a request lands in an approver inbox. The result is fewer hand corrections and a clear reason whenever a request is rejected.
Yes. Most rules are configurable per leave type, per team, or per individual where it matters. A finance team can keep stricter advance notice while engineering uses shorter lead times. Probation windows can apply to recent hires only. Country-specific accrual ladders can run alongside a flat US policy.
Auto-approval runs against criteria you set. Leave type, duration, time of year, employee tenure, and team coverage are common filters. A two-day sick request from a non-probation employee with no team conflict can be approved on submission. A two-week vacation in a blackout window cannot. Anything that fails a check routes to the configured approval chain for human review.
Seniority accruals run automatically. You define tiers by years of service (for example, 20 days at 0 to 2 years, 22 days at 3 to 5 years, 25 days at 6+ years). The system uses the employee start date to apply the right tier and updates the balance when the employee crosses a threshold. HR does not need to edit the balance by hand.
That depends on your carryover settings. You can disable carryover entirely (use it or lose it), allow uncapped carryover, or set a cap with an expiry date (for example, carry up to 5 days, expire on March 31). The engine moves balances on the rollover date and flags expiring days in advance so employees can plan.
Yes. Blackout dates are date-range windows you configure per company or team. When an employee picks dates that overlap a blackout, the request is rejected at submission with a clear reason. You can leave a note on the blackout so the employee knows why and when the window opens again.
Auto-approval runs first. If a request meets the criteria, it never enters the approval chain. If it does not, the configured chain takes over: sequential or simultaneous, scoped approvers per role, voting policies (any one, majority, all must approve). You can read more on the multi-person approval page.
Pricing
The rules engine is included in every BreezeLeave plan, including the free tier for teams of 10 or fewer. There is no separate "automation" upsell. See the pricing page for current plan details, or read the auto-approval use case if you want to see a focused example of what auto-approval can cover on its own.