> 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/run-the-roster/cross-department-cover.md).

# Lend staff between departments

Departments in ReSouris are fenced from each other: a roster area sees the people it owns. A **cross-department cover rule** is how you deliberately open a gap in that fence — "Radiology may draw on these three sonographers from Cardiology for the next quarter" — without merging the two departments or moving anybody's employment.

**Where:** sidebar → **Fairness & cover** → **Cross-department cover** (`/ui/admin/cross-cover`).

**You need:** `cross_department_cover.write`, held by `rostering_manager` and `tenant_admin`.

## What a rule says

Every rule names a direction and a window:

| Field                 | Meaning                                                                            |
| --------------------- | ---------------------------------------------------------------------------------- |
| **Source department** | Who is lending. The people come from here.                                         |
| **Target department** | Who is borrowing. The roster being solved is here.                                 |
| **Kind**              | `individual_staff` — one named person. `role_template` — everybody holding a role. |
| **Effective from**    | The first date the rule applies. Required.                                         |
| **Effective to**      | The last date. Leave it empty for an open-ended grant.                             |

> ⓘ **The direction matters and is not symmetric.** A rule letting Cardiology lend to Radiology does not let Radiology lend back. Create the second rule if you want that. A rule cannot name the same department twice.

## What it does to a roster

When the solver builds the universe for the target department's horizon, it:

1. Adds the covered staff to the candidate pool for that department's sessions.
2. **Removes any candidate who is already assigned in their home department at that time.** There is no separate conflict table — the single source of truth is that the person is already assigned, so a borrowed colleague can never be double-booked.
3. Treats them as ordinary candidates thereafter: the same competency requirements, the same fairness accounting, the same [decision order](/how-it-works/equity-model.md#the-decision-order).

So a cover rule widens who *may* be scheduled. It does not oblige anyone to be, and it does not promote a borrowed person above the department's own staff.

## The two traps

> ⛔ **A LAPSED RULE IS STILL `active` UNTIL SOMEBODY ARCHIVES IT, AND NOBODY ARCHIVES ON THE DAY.** What counts is whether the rule is **in force over the horizon being solved** — not whether its state says `active`. A rotation that ended last month lends nobody to next month's roster, and one that starts in January lends nobody to December. Both still show as `active` rows. If a roster seems to be ignoring a cover rule, check the dates before anything else.

> ⚠️ **A `role_template` RULE EXPANDS TO EVERY HOLDER OF THAT ROLE, AND IS CAPPED AT 200.** It is the convenient option and the easy mistake: "everyone with this role" in a large tenant can mean hundreds of people, which makes the solve far larger for no scheduling benefit. The expansion is bounded so a misconfigured rule cannot make rosters unsolvable, and the screen warns you when a rule would exceed the cap. Prefer `individual_staff` when you know who you mean.

## Managing rules

The list shows **every** rule in the tenant, including expired and not-yet-started ones. That is deliberate — those are usually the rows you came to fix, and hiding them would make a lapsed rotation look like a grant nobody ever created.

**Archiving** is a soft delete: the rule moves to `archived` and stops affecting rosters, but the row survives so the audit trail still explains why last quarter's roster looked the way it did. Rules are never hard-deleted.

## Related, but not the same thing

* **The availability pool** lets one department lend a spare session in its room to another, without either owning the other's staff. If the problem is a room rather than a person, see [Lend a space to another department](/set-up-what-you-schedule/lend-a-space.md).
* **Federation** is the same idea between *organisations* rather than departments, and needs a signed agreement from both sides — see [Share cover between organisations](/part-2-running-resouris/federation.md).
* Department scoping itself — what a roster area can see at all — is described under [Roles and access](/part-2-running-resouris/permissions.md#departmental-scoping).


---

# 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/run-the-roster/cross-department-cover.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.