> ## Documentation Index > Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt > Use this file to discover all available pages before exploring further. # Leave Block Lists > A leave block list lets you freeze leave on specific dates — the days nobody (or almost nobody) may take off. A leave block list lets you freeze leave on specific dates — the days nobody (or almost nobody) may take off. The classic example is a year-end financial close, a stocktake week, a peak trading period, or a system go-live, where the business simply cannot afford people being away. Once a date is on a block list, any leave application that touches it is refused at submission time, with a message naming the block list and the reason. This page covers creating a block list, scoping it to a department or leave type, letting certain roles bypass it, and how the block is enforced when someone applies for leave. **You'll find this at:** `/settings/erp/people/leave` — open the **Block Lists** tab. > Block lists belong to a **business** (or can be made tenant-wide). A block list left without a business applies across all your businesses; one tied to a business only blocks that business's leave. Check the business switcher before you create one. > 📷 *Screenshot: the Block Lists tab with the list of block lists and the "Add Block List" button — to be added.* *** ## What a block list is made of A block list has three parts: 1. **The list itself** — a name and an optional reason, plus its scope (which business, and optionally which department and which leave type it applies to). 2. **Blocked dates** — one or more specific calendar dates, each with its own optional reason. 3. **Allow roles** — the roles, if any, that are permitted to take leave *despite* the block. *** ## Creating a block list On the **Block Lists** tab, choose **Add Block List**. > 📷 *Screenshot: the Add Block List form — name, reason, the blocked-dates table, and the allow-roles input — to be added.* | Field | Required | Notes | | ----------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Yes | A short label, e.g. "Year-end freeze 2026". | | **Reason** | No | Why leave is blocked — shown to anyone whose request is refused. | | **Blocked Dates** | Yes | At least one date. Each row is a date plus an optional per-date reason. Add and remove rows as needed; duplicate dates are stripped out automatically. | | **Allow Roles** | No | Roles that may bypass the block (see below). | The form refuses to save without a name and at least one date. *** ## Scoping a block list Beyond the business it belongs to, a block list can be narrowed: * **By department (org unit).** Left unset, the block applies to everyone; set it, and only that department's staff are blocked. * **By leave type.** Left unset, the block applies to *all* kinds of leave; set it, and only that leave type is blocked (so you could, for example, freeze Annual Leave at year-end while still allowing Sick Leave). > ⚠️ **Current state:** the department and leave-type scoping are supported by the system, but the **Add Block List** form does not currently expose fields for them — block lists created through the screen apply to the whole business and to all leave types. To use the narrower scoping today you'd need the API. (Flagged for the team.) *** ## Letting certain roles bypass a block Sometimes the rule needs an exception — perhaps senior managers or board members may still take leave during the freeze. Add their **roles** to the **Allow Roles** list and people holding those roles will not be blocked. There is also an all-or-nothing override on the list: when **Apply block list to all** is turned on, *even the allow-roles cannot bypass it* — the block is absolute. (This is on by default behaviour when no allow-roles are set; with allow-roles set, those roles bypass unless "apply to all" is on.) Role matching is case-insensitive and tolerant of the internal role-name suffix Hitaji uses, so you can enter roles by their plain names. *** ## How the block is enforced A block list does nothing on its own — it bites when someone **applies for leave**. As a leave request is created, Hitaji checks the requested date range against every active block list that applies to the employee's business (and department/leave type, where scoped). If any blocked date falls inside the requested range — and the applicant doesn't hold a bypassing role — the request is **refused** with a message of the form: > *Leave blocked by "Year-end freeze 2026" on 29 Dec, 30 Dec, 31 Dec — Financial close.* The check is by calendar day, so the time of day is irrelevant. *** ## Removing a block list Deleting a block list **deactivates** it (a soft delete) — it stops being enforced but the record is retained. There is no edit-in-place; to change blocked dates, deactivate the old list and create a fresh one. *** ## Permissions | Action | Permission | | ----------------------------- | ---------------------------------------------- | | View block lists | (open to any signed-in user with leave access) | | Create or delete a block list | `hr-leave:config` | The `hr-leave:config` permission is the same one that governs leave types, allocations, and holiday lists — the leave-configuration role. *** ## Related * [Leave overview](/hr/user/leave/overview) — how leave configuration fits together * [Applying for & approving leave](/hr/user/leave/leave-requests) — where the block is hit * [Holiday lists](/hr/user/leave/holiday-lists) — public holidays and weekly offs (distinct from block lists) * [Leave periods](/hr/user/leave/leave-periods) — the annual period allocations run against * [Org Structure — departments, seats & reporting lines](/hr/user/getting-started/org-structure) — the departments a block list can be scoped to