> 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/set-up-what-you-schedule/room-sl-schedule.md).

# Space and service-line scheduling

**Who:** roster-area admin or tenant admin with `admin.clinic.*` perms. **Time:** \~5 minutes for a first weekly pattern; \~1 minute per one-off override.

ReSouris v1.6.4 exposes the P24-shipped `room_service_line_pattern` + `room_service_line_override` tables to admin self-serve. Prior to v1.6.4 these tables were solver-consumed but author-less; fixtures or direct DB inserts were the only way to populate. The v1.6.4 rooms-screen editor closes that gap.

## When to use

* **Recurring weekly rule** — "Room 4 is Service Line A on Mondays and Wednesdays, Service Line B on Tuesdays, Thursdays, Fridays." Author once; the solver reads the pattern for every future rota.
* **One-off exception** — "…but on Monday 2026-08-03 Room 4 runs Service Line B." Author as an override; supersedes the pattern for that date.

## Where to find it

Sidebar → **Organisation** → **Spaces** → click the space row → follow the "Schedule" link (or navigate directly to `/ui/admin/spaces/{room_id}/schedule`).

## Weekly pattern

1. In the Weekly pattern section, pick a service line per Mon-Sun × AM/PM cell. Empty cells fall back to the room's static default.
2. Use the Bulk-apply row to fill many cells at once: pick a service line, tick the weekdays, tick AM and/or PM, click Bulk-apply.
3. Click **Save pattern (idempotent full-replace)**. The whole pattern set is written atomically.

## Date overrides

1. In the Date overrides section, pick a date (today or later, within the horizon), pick AM or PM, pick a service line, click **Add override**.
2. The override appears in the list below, highlighted yellow. Click Clear to remove.

## Satisfiability warning

If any pattern cell references a service line the room cannot host, a yellow warning banner appears listing the unreachable cells. The pattern still saves — this is a soft signal per the phase's F6 lock — but the solver will refuse those cells with `PRE_FILL_CONFLICT` until you add a clinic that hosts the SL.

## Audit trail

Every write emits an audit event:

* `room_sl.pattern.replaced` — with removed / inserted row counts
* `room_sl.override.set` — one per upserted override
* `room_sl.override.cleared` — one per cleared override

Filter the audit page by these action strings for the room's scheduling history.

## API surface

Six routes for programmatic use, all under `/v1/admin/rooms/{room_id}/`:

* `GET service-line-pattern` — read the current pattern.
* `PUT service-line-pattern` — idempotent full-replace.
* `GET service-line-overrides` — list current overrides.
* `PUT service-line-overrides` — upsert one override.
* `DELETE service-line-overrides/{on_date}/{subslot_index}` — clear one.
* `POST service-line-schedule/validate` — pre-check satisfiability.

All six gate on `admin.clinic.read` or `admin.clinic.update`.

## Limitations (v1.6.4)

* **AM/PM authoring only.** The underlying tables carry a 0..47 subslot index but the v12 solver only maps at AM/PM granularity today. Finer subslots are deferred to whenever the solver consumes them.
* **Overrides bounded** to today plus a 365-day horizon. Past dates refused server-side; beyond-horizon dates rejected in the picker.
* **Warning, not blocking.** Satisfiability check is advisory. Legitimate to author a rule before the room mlinic mapping exists.

## What comes next

* Understand the roster lifecycle these rules feed into → [Roster lifecycle](/how-it-works/roster-lifecycle.md).
* Understand the architecture → [Architecture](/reference/architecture.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/set-up-what-you-schedule/room-sl-schedule.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.