> For the complete documentation index, see [llms.txt](https://help.resouris.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.resouris.com/for-clinical-staff/submit-a-leave-request.md).

# Submit a leave request

**Who:** worker or roster-area admin (admin acts on-behalf). **Perm:** `my_details.leave.submit` (worker), `admin.leave-requests.decide` (admin on-behalf). **Time:** \~2 minutes.

Leave requests are a proper state machine — not an ad-hoc email chain. Submitting one produces an auditable trail from request through decision, and the reschedule worker automatically covers the affected sub-slots when the request is approved.

## Before you start

* You need an account in the tenant with a `worker` (or similar) role.
* Check your **leave balance** first — it appears at the top of `/ui/my-roster/leave`. Submitting a request beyond your balance is allowed but the deciding admin will see the balance warning.

## 1. Navigate

Sign into `/ui/my-roster`. Click the **Leave** tab, then **New request**.

If you're on a mobile device, the same flow is available — the form is responsive.

## 2. Fill the request

* **From** — first day of leave.
* **To** — last day of leave. Inclusive on both ends. Same-day leave allowed.
* **Kind** — pick from the closed-set dropdown:
  * `annual` — standard annual leave.
  * `study` — study leave (usually excluded from the equity denominator; see the tenant's allocation policy exclusions).
  * `sickness_followup` — extending sickness beyond the acute report.
  * `compassionate` — bereavement, family emergencies.
  * `unpaid` — unpaid leave.
  * `other` — free-text reason required in the notes.
* **Notes** — free-text detail. Visible to the deciding admin. Optional except when `kind='other'`.
* **Contact if urgent** — checkbox. If set, the deciding admin gets a nudge to expect your response during working hours if a schedule clash needs discussion.

## 3. Submit

Click **Submit request**. The request enters state `pending`.

Confirmation:

* You see a toast + a new row in the **Pending** tab of your leave dashboard.
* Email confirmation lands in your inbox (if notifications are enabled on your account).
* Audit event `leave.request.submitted` written to the tenant chain.

## 4. Wait for the decision

Your roster-area admin sees the request on `/ui/admin/leave-dashboard`. Their SLA depends on the tenant's leave workflow — typically 1-3 working days.

When they decide, you get a notification:

* **Approved** — badge on `/ui/my-roster` nav; the affected days appear as leave in your roster; the reschedule worker begins backfilling your published assignments.
* **Denied** — badge with the admin-authored reason. You can re-submit with amended dates.

## 5. Withdraw (only while pending)

While the request is `pending`, you can withdraw it:

1. Click into the request from the Pending tab.
2. Click **Withdraw**.
3. Confirm.

The row transitions to `withdrawn`. State preserved for audit — not hard-deleted.

**Once approved, you cannot withdraw directly.** Contact your admin; they use the admin-on-behalf action to move the request back down. This preserves any rescheduling that was already performed.

## 6. Track over time

The Leave tab has four filter chips: **Pending | Approved | Denied | Withdrawn**. Your history is queryable indefinitely (subject to your tenant's retention window; typically 7 years for audit rows).

The **notify-back badge** on the nav counts decisions you haven't seen yet. Clicking any row marks it as seen and decrements the count.

## Admin-on-behalf (`?skip_pending=true`)

Roster-area admins can create a leave request on behalf of a worker when the worker cannot submit themselves (e.g. bereavement leave phoned in). The leave dashboard at `/ui/admin/leave-dashboard` carries the log-on-behalf action.

The submitted-by-user-id is left NULL on those rows, which is how the system distinguishes operator-authored requests from self-submitted ones. Audit event `leave.request.submitted_on_behalf` fires.

## Composability

Approved leave interacts with:

* **Rostering** — the reschedule worker produces proposals for every sub-slot in the leave window that had a published assignment for you. Your admin accepts covers on the reschedule-proposals page.
* **Equity model** — approved leave is typically excluded from the equity denominator (per the tenant's allocation policy). Ask your admin if you think an exclusion should apply and doesn't.
* **Job plans** — leave doesn't reduce your job-plan entitlement targets, but the credited-count doesn't accumulate during your absence. Post-leave, you may see a bump in `entitlement_debt` — this is expected and the solver corrects for it over the following weeks.

## Common issues

* **"Can't submit — dates overlap another request"** — you already have a pending or approved request covering some of these dates. Withdraw the other one first, or amend the new one.
* **"Denied with no reason"** — deniers should always include a reason. If yours didn't, it's a workflow-config issue on the tenant side; ask your admin.
* **"Approved but I'm still on the roster"** — the reschedule worker runs asynchronously. Your approved leave shows on your calendar view but the underlying `slot_assignment` rows are transitioned as the reschedule proposals are accepted. Typically clears within an hour of approval on a healthy system.

## What comes next

* Understand how the decide + reschedule flow works from the admin side → [Roster lifecycle](/how-it-works/roster-lifecycle.md#post-publish-disruption).
* See the full sickness + leave state machine → [Sickness and leave](/how-it-works/sickness-and-leave.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.resouris.com/for-clinical-staff/submit-a-leave-request.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.