> ## 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 Allocations (Control Panel) > Defining a leave type gives you a rule; it does not give anyone a usable balance. Defining a leave type gives you a *rule*; it does not give anyone a usable balance. **Allocation** is the step that grants real days to real employees, creating the balances they can then spend. The **Leave Control Panel** does this in bulk: pick a group of employees, choose what they should get, preview exactly who is affected, then commit. Allocation is the right way to seed balances because it creates a proper ledger credit for each employee — so every granted day is auditable and reconciles against the balance. (Adjusting one person's balance by hand from their profile is a different, narrower tool — see the note at the end.) **You'll find this at:** `/hr/leave/allocations` > Allocation always targets your **active business**. The control panel reads the business from the switcher at the top of the app, and the server rejects any attempt to allocate into a different business. If no business is selected, the panel tells you to switch to one first. Re-run the preview whenever you change business. > 📷 *Screenshot: the Leave Control Panel with the settings card on the left and the preview table on the right — to be added.* *** ## The two modes The panel works in one of two modes, chosen from the **Mode** dropdown. They serve genuinely different purposes and behave differently when you run them more than once: | Mode | What it does | What you must supply | Can you re-run it? | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Annual Entitlement** | Gives each matched employee the standard entitlement defined by a **leave policy**, creating a proper policy assignment for the contract. This is the everyday way to seed the year's annual entitlement. | A **Leave Policy**. | Runs **once per employee per policy period**. Re-running it is a safe no-op for anyone already allocated — they're skipped, not double-credited. | | **Ad-hoc Top-up** | Credits a specific **number of days** of a chosen **leave type** directly to each matched employee's balance. Useful for one-off grants, corrections, or bonus days. | A **Leave Type** and a **Number of Days** (a positive multiple of 0.5). | Has **no repeat guard** — every run is treated as intentional and adds to the balance. Run it as many times as you need, but double-check your filters and day count before committing, since nothing will stop a second run from crediting the same group again. | > Seed annual entitlements through **Annual Entitlement** so they are correctly tied to each contract and policy. Reach for **Ad-hoc Top-up** only when you deliberately want to add extra days outside the normal entitlement cycle. *** ## Choosing who gets the leave Below the mode you narrow the target group with optional filters. Leave any of them on "All" to include everyone in the active business: | Filter | Effect | | ------------------- | -------------------------------------------------------------- | | **Department** | Restrict to one department. | | **Designation** | Restrict to one position/designation. | | **Employment Type** | Restrict to *Full Time*, *Part Time*, *Contract*, or *Intern*. | That's it — there's no date range or carry-forward option to set here. Carry-forward behaviour at year end is controlled entirely by the **leave type's** own settings (its carry-forward percentage and maximum carried days), not by anything you choose at allocation time. See [Leave types & settings](/hr/user/leave/leave-types) to configure that. *** ## Preview before you commit Allocation is deliberately a two-step action. 1. Choose **Preview**. The right-hand table fills with every employee the filters matched, showing each person's **Current Balance** and the **New Allocation** they would receive. 2. Review the list carefully. If anything looks wrong, change a filter — **changing any setting clears the preview**, so you can never accidentally commit an allocation against a different group than the one you reviewed. 3. When the preview is correct, choose **Allocate (N)** (the count is shown on the button). Hitaji credits the balances, then confirms how many employees were allocated. If you try to allocate without a current preview, the panel asks you to preview first. *** ## What allocation actually does * **Annual Entitlement** creates (or confirms) a **leave policy assignment** linking the contract to the policy, and writes a **positive ledger entry** (transaction type *Allocation*) that bumps the **Accrued** figure on that contract's balance for the period. An employee who already has an assignment for that policy/period is skipped. * **Ad-hoc Top-up** skips the assignment step entirely and writes the **positive ledger entry** straight to the employee's balance. There's no assignment record and no skip check — each run is a deliberate, standalone credit. Because every grant is a ledger row either way, you can later see exactly who allocated what and when on the [Leave ledger report](/hr/user/leave/leave-reports). *** ## Who can allocate Reaching the page needs **`hr-leave:config`**. The allocation endpoints themselves additionally require **`hr:admin`**, so the person committing the allocation must hold that broader HR-admin permission. | Action | Permission | | --------------------------------- | ----------------- | | Open the Leave Control Panel page | `hr-leave:config` | | Preview / execute an allocation | `hr:admin` | *** ## Allocation vs. a manual balance adjustment There are two ways a balance can change outside of an approved application, and they are not interchangeable: * **Bulk allocation (this page)** writes a proper ledger credit for each matched employee. This is the correct way to grant entitlements or top-ups — the balance is properly tied to the contract and policy, so applications draw against it. * **A manual adjustment** (the *adjust balance* action available to `hr:admin` from an employee's leave detail) writes a one-off correction. A manual adjustment is **not** tied to a contract in the same way and should be reserved for genuine corrections, not for seeding entitlements or top-ups. If you allocate by hand via the adjust tool, an application may not find a contract-scoped balance to draw against. When in doubt, allocate through the control panel. *** ## Related * [Leave overview](/hr/user/leave/overview) — how allocation fits the wider flow * [Leave types & settings](/hr/user/leave/leave-types) — define the types, policies, and carry-forward rules you allocate against * [Applying for & approving leave](/hr/user/leave/leave-requests) — how balances are spent * [Leave reports (balance & ledger)](/hr/user/leave/leave-reports) — audit what was allocated * [Leave periods](/hr/user/leave/leave-periods) — the periods allocations roll against