> ## 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 Policies

> A leave policy is the approval-and-limits layer of the leave module — it sets the notice period, the longest stretch allowed, and whether requests need an approver.

A **leave policy** is the rule-set that decides *how a leave request is handled*: how much notice is required, the longest single stretch someone may take, and whether a request needs an approver or clears automatically. Where a [leave type](/hr/user/leave/leave-types) defines *what a kind of leave is* (how it accrues, carries forward, and is paid), a policy defines *how requests against leave are governed*.

Policies are the label your people actually see. The name shown on the leave list, the calendar, and the apply form comes from the **policy** an employee holds a balance under — so a clearly named policy ("Annual Leave", "Sick Leave") reads well everywhere.

**You'll find this at:** `/settings/erp/people/leave` (the **Leave Policies** tab)

> 📷 *Screenshot: the Leave Settings page on the Leave Policies tab, showing the policies table — to be added.*

***

## Creating or editing a policy

On the **Leave Policies** tab choose **Add Policy** (or click a row to edit). The form is short — only the name is required.

| Field                    | Required           | Notes                                                                                                                      |
| ------------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| **Name**                 | Yes                | The label employees and approvers see on requests and balances. E.g. *Annual Leave Policy*.                                |
| **Description**          | No                 | Free text.                                                                                                                 |
| **Min Days Notice**      | No                 | The minimum lead time, in days, between submitting a request and its start date. Leave blank for no minimum.               |
| **Max Consecutive Days** | No                 | The longest single unbroken stretch a request under this policy may cover. Leave blank for no cap.                         |
| **Requires Approval**    | No (on by default) | When on, requests go to *Pending Approval* and wait for an approver. When off, requests clear automatically on submission. |
| **Active**               | No (on by default) | Inactive policies stay on record but are not offered for new allocations or requests.                                      |

That is the **entire** policy form today. There is intentionally no accrual, carry-forward, or business-scope field here — those rules live on the **leave type**, not the policy.

> Managing policies needs **`hr:admin`**. Viewing them needs only general HR read access.

***

## How a policy relates to a leave type

This is the part that most often causes confusion, so it is worth being precise.

Under the hood, every leave policy *can* reference a single leave type, and a balance an employee holds is tied to a policy. Conceptually the chain is:

```
Leave Type  →  Leave Policy  →  Allocation/Entitlement  →  Employee balance
(the rules)     (the approval     (real days for a            (what gets spent)
                 wrapper)          period)
```

**Important — the policy form does not currently let you pick a leave type.** When you create a policy in the app you give it a name and the notice/approval rules above; you do **not** select which leave type it belongs to from this screen. The two lists — **Leave Types** and **Leave Policies** — are maintained independently in the UI.

That has a direct, visible consequence:

> ### "I added a leave type but it doesn't show under Leave Policies"
>
> That is expected with the current build. Creating a leave type does **not** create a policy, and the Leave Policies tab has no field that lists or selects leave types — so a new type will never "appear" there. The in-app hint *"policies attach to a type"* describes the intended data model; the on-screen link between the two is not yet exposed. To make a leave type usable you create the type **and** create a policy (and then allocate it), as two separate steps.

Types and policies are brought together at **allocation** time, on the [Leave Control Panel](/hr/user/leave/leave-allocations):

* **Assign by Policy** — give matched employees the entitlement for a chosen **policy**.
* **Allocate by Type** — grant a number of days of a chosen **leave type** directly.

So in practice you pick *either* a policy *or* a type when you allocate; you do not wire one to the other beforehand from the policy form.

***

## Eligibility and gender restrictions

A common question: *can I make Maternity leave available only to women (or Paternity only to men)?*

**Not as a hard rule today.** Neither the leave type nor the leave policy has a gender or eligibility field. The only built-in eligibility gate is **Applicable After (days)** on the leave type — a probation gate that blocks a type until an employee has been on contract for a set number of days. Nothing in the system will stop a male employee from being given a "Maternity" balance if someone allocates it to him.

The practical way to keep gender-specific leave on the right people:

* **Allocate selectively.** Leave is only usable once it is allocated. If you only ever allocate Maternity leave to the relevant employees (allocate by policy/type to the specific people, rather than a blanket "everyone" allocation), no one else gets a balance to draw on.
* **Name it clearly** so approvers can spot a wrong request.
* **Use the leave approver** as the human check — a maternity request from someone who shouldn't have it is caught at approval.

If a *enforced* gender/eligibility rule matters for your organisation, that is a feature request rather than a configuration step — flag it to your administrator.

***

## Deleting a policy

Deleting a policy is guarded: entitlements and allocations that reference it may be affected, and the app warns you before it removes the row. Prefer marking a policy **Inactive** over deleting it if it has ever been allocated, so historical balances keep their label.

***

## Permissions

| Action                                | Permission                              |
| ------------------------------------- | --------------------------------------- |
| View leave policies                   | Any authenticated HR user               |
| Create / edit / delete a leave policy | `hr:admin`                              |
| Allocate a policy to employees        | `hr:admin` (on the Leave Control Panel) |

***

## Related

* [Leave overview](/hr/user/leave/overview) — how all the pieces fit together
* [Leave types & settings](/hr/user/leave/leave-types) — the accrual and rule master that policies sit on top of
* [Leave allocations (control panel)](/hr/user/leave/leave-allocations) — turn a policy or type into real balances
* [Applying for & approving leave](/hr/user/leave/leave-requests) — how balances are spent
* [Leave periods](/hr/user/leave/leave-periods) — the windows balances roll against