Leave Settings control how leave behaves across your Rotageek tenant: which leave types exist, who can approve which requests, and how rules like blocked days and “max people off” are enforced.
To open this area:
Go to the Rotageek web app.
Open Admin Console.
Select Leave Settings in the left‑hand menu.
1. General settings
The General Settings tab defines global leave behaviour for your whole group.
Leave year start date - Sets the official start of your leave year (e.g. 01 Jan). This drives how annual leave entitlements and balances are calculated and displayed.
Leave escalation period - A number of days used when escalating or following up leave requests. In most setups this is configured for you during implementation and rarely changed.
Projected days cap - Limits how far ahead projected leave balances are calculated (in days). This helps keep balance projections realistic for long future periods.
Max on leave validation setting -Controls how strictly the system enforces “max people off” rules when a request is made:
Off – ignore max people off when validating requests.
Soft block – allow requests but show a warning if the max would be exceeded.
Hard block – block requests that would take you over the configured maximum.
Toggles in Settings
These switches refine how requests look and behave:
First‑come‑first‑leave processing - When enabled, requests are processed in the order they were submitted, which is helpful if you are strictly enforcing max people off.
Quick action buttons - Shows shortcuts on the Outstanding tab in Leave Admin, making it faster for managers to approve or reject requests from a list view.
Add ‘notes’ to leave requests - Allows managers to add internal comments when processing leave (for example, why an exception was approved).
Include cost of leave in payroll costs - If enabled, approved leave contributes to rota cost totals and reporting, alongside worked hours.
Align leave year start date to start day of week - Aligns the leave year start date to the first day of your scheduling week (e.g. Monday) so leave years and rota weeks line up.
Allow Leave Cancellation Requests - Lets employees submit cancellation requests for already‑approved leave, subject to your request windows and approval rules.
Split leave requests into individual days - When enabled, longer leave requests are stored as individual day entries. This can make reporting and some adjustments easier to manage.
2 . Leave Types
The Leave Types tab defines each leave type employees and managers can use (e.g. Annual Leave, Sickness, TOIL, Maternity).
The list view shows, for each type:
Description – the leave name visible to users.
Absence code – the payroll code used when exporting to payroll.
Locations – where this leave type is available (for example, specific stores or “All Locations”).
Status – typically Active or Inactive (archived).
Adding or editing a leave type
Open Admin Console → Leave Settings → Leave Types.
To create a new type, click Add leave type. To change an existing one, click its row.
Key fields when configuring a leave type:
Description / Public description – the internal and (optionally) public name that appears in calendars and request screens.
External ID / Absence code / Default absence code – how this leave type is mapped to your payroll system.
Type (Paid / Unpaid) – whether this leave is paid or unpaid.
Locations – which locations can use this leave type.
Deduct from / Has allowance – which allowance bank is used, and whether this type tracks an allowance at all.
Allow negative leave balance – whether employees can go below zero on this allowance, and whether that is a soft warning or a hard block.
Allowed overlapping tasks – lets certain tasks overlap with leave (for example, KIT days).
Options that control visibility and behaviour:
Requestable – whether employees can request this type in the app.
Only visible on week view to supervisors and admins – hides the type from standard employee views.
Display on dashboard schedule / Show leave type name – how it appears on rotas and dashboards.
Requires document attachment / Requires reason – forces users to upload a document or provide a reason when using this type.
Replace existing shifts only / Block partial day requests / Disallow leave day duration override – how leave interacts with existing shifts and whether managers can adjust calculated durations.
Always cap leave duration to leave allowance – shorten requests automatically so they never exceed remaining balance.
Contributes to basic threshold / Ignore worked hours in week for leave day durations / Zero Hour Leave – advanced behaviours for pay rules and duration calculation (for example, recording zero‑hour events that do not alter balances).
Tip: For types that should be tracked but not limited by an allowance (for example some sickness types), either leave Has allowance off or combine it with a relaxed negative balance rule so employees are not blocked from booking required leave.
3. Leave Approval
The Approval Settings tab defines which positions can approve leave for which other positions, and where escalation should apply.
The screen has:
A left‑hand list of Positions – these are the approver positions (for example, Store Manager).
A central table of Positions to process – the positions whose leave requests they can handle (for example, Team Member).
Two columns of checkboxes for each processed position:
Approve – this approver position can approve or reject leave for that position.
Escalation – this approver is part of the escalation chain for that position’s leave requests (for example, second‑level approver).
Configuring approval rules
Open Admin Console → Leave Settings → Approval Settings.
In the left panel, click the approver position you want to configure.
In Positions to process, tick:
Approve where this position should be able to approve/reject leave directly.
Escalation where this position should receive escalated requests.
Click Save to apply the rules.
Use this tab to reflect your real‑world approval hierarchy (for example, supervisors approving team requests, with HR or head office as escalation).
Request Rules
The Request Rules tab lets you configure company‑wide rules about when leave can be requested and how many people can be off at once.
The page has three main sections:
Blocked days
Max people off
General settings for how strict those rules are
4.1 Blocked days
Use Blocked days to define date ranges where leave is restricted (for example peak trading weeks, stock‑takes or major events).
The table includes:
Name – the rule name (e.g. “Christmas”, “Thanksgiving”).
Date – start and end date range.
Location – which locations it applies to (e.g. “All Locations” or specific sites).
To add or edit a blocked days rule:
Go to Admin Console → Leave Settings → Request Rules.
In Blocked days, click Add rule (or edit an existing one).
Enter a Name, select the Date range, and choose the Location(s).
Save the rule.
Depending on your Blocked days general setting (see below), requests in these periods will be either blocked or allowed with a warning.
4.2 Max people off
Max people off limits how many people can be on leave for a given location (and optionally specific positions) at the same time.
The table includes:
Name – rule name (e.g. “Store limit – weekdays”).
Max people off – the maximum number allowed off concurrently.
Location – which location(s) the rule applies to.
Positions – optional filter so the rule applies only to certain positions.
To add or edit a max people off rule:
In Request Rules, scroll to Max people off.
Click Add rule (or edit an existing one).
Enter a Name, the Max people off number, and select Location and (optionally) Positions.
Save the rule.
How strictly these limits are enforced depends on the Max on leave general setting.
4.3 General settings (for Request Rules)
At the bottom of the Request Rules page you’ll see a General settings panel with two dropdowns:
Blocked days
Off – blocked days don’t affect validation.
Soft block – requests in blocked periods are allowed but highlighted to managers.
Hard block – requests in blocked periods are blocked and cannot be submitted.
Max on leave
Off – ignore “max people off” rules when validating new requests.
Soft block – allow requests that go over the max, but flag them for review.
Hard block – block requests that would exceed the configured max people off.