> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ontime.hosai.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Swaps and open shifts

> Let employees trade shifts or claim unfilled ones, with configurable auto-approval rules and a coverage view.

export const PermissionNote = ({perm}) => <Info>
    Requires the <code>{perm}</code> permission. Ask your administrator if an
    action described here is missing from your screen — see
    [Roles & permissions](/help/concepts/roles-and-permissions).
  </Info>;

A published roster is a plan, not a prison. Two mechanisms let it change without an administrator rebuilding the week:

* A **swap** — two employees trade shifts.
* An **open shift** — an unfilled shift is posted for anyone eligible to claim.

**Shifts & rosters → Swaps.**

## Requesting a swap

<PermissionNote perm="swap:write" />

An employee nominates a counterparty and the two dates to exchange. The board immediately shows a **compatibility check** for that pairing:

| Check          | Passes when                                                   |
| -------------- | ------------------------------------------------------------- |
| **Same team**  | Both employees are in the same department.                    |
| **Same shift** | Both shifts share a category (`G`, `M`, `E`, `N`, `F`).       |
| **Rest gap**   | Neither side moves on or off a night shift within the window. |
| **Consent**    | Both parties agreed in-app.                                   |

Each failing check names the review it triggers, so the requester can see up front whether their swap will sail through or need a decision.

## Posting an open shift

An unfilled shift is posted to the eligible team. Employees register **interest** by claiming it, and can withdraw again.

<Note>
  **Claiming is self-only.** Nobody can claim an open shift on another employee's behalf.
</Note>

Approving an open shift requires naming the winning claimant — the approver picks from the people who registered interest.

## Auto-approval rules

<PermissionNote perm="swap:write" />

The **Auto-approval rules** rail is a real, editable rules engine. Each rule can be enabled or disabled, and set to one of three actions:

| Action          | Effect                                            |
| --------------- | ------------------------------------------------- |
| `autoApprove`   | Swaps triggering only this rule need no decision. |
| `managerReview` | A manager must decide.                            |
| `hrCoApprove`   | HR co-approval is required.                       |

Five rules ship seeded:

| Rule                   | Triggers when                                           | Default action  |
| ---------------------- | ------------------------------------------------------- | --------------- |
| `same-shift-same-team` | The clean case: same team, same shift, no rest concern. | `autoApprove`   |
| `min-rest-8h`          | The swap moves someone on or off a night shift.         | `autoApprove`   |
| `cross-team`           | The two employees are in different departments.         | `managerReview` |
| `pay-rate-change`      | The two shifts have different categories.               | `hrCoApprove`   |
| `within-ot-cap`        | —                                                       | `autoApprove`   |

A swap auto-approves only if **every** rule it triggers is enabled *and* set to `autoApprove`. Disabling `same-shift-same-team` genuinely flips every clean swap back into review.

<Warning>
  **Two things to check before you rely on the defaults.**

  `min-rest-8h` ships set to `autoApprove` — so a swap that shortens someone's rest below eight hours auto-approves out of the box. If rest gaps matter to you, tighten it to `managerReview` or `hrCoApprove` before go-live.

  `within-ot-cap` is **not currently evaluated**. The rule is persisted, editable and shown in the rail, but no swap triggers it, so changing it has no effect on any decision.
</Warning>

## Approving

<PermissionNote perm="swap:approve" />

Approving a swap **atomically rewrites the roster cells**. Both employees' assignments move in one transaction — there is no state where one side of a swap has been applied and the other has not.

Rejecting persists the approver's note on the request.

**Bulk approve** advances several swaps at once. It never aborts the batch: each swap that cannot be approved is skipped and reported with its reason, and the rest go through.

<Note>
  `swap:approve` sits with HR and Admin, not with Manager. Managers hold `swap:write` — they request swaps; HR approves them.
</Note>

## Coverage

The **Coverage** tab shows staffed versus open shifts across shift category and day of week for the period — a grid that makes a thin Saturday night obvious before it becomes a problem.

## Export

The swap board exports to CSV, honouring the current filters.