> 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/equipment-mandatory-and-maintenance.md). # Mandatory service lines and equipment Three changes that landed together in v1.7.8, all aimed at the same problem: making sure the sessions that *must* run are visible when they don't, and that the kit those sessions depend on is actually available. ## Mandatory service lines Some clinical work cannot simply not happen. Until now the only way to say so was at the clinic level, which was too coarse — a clinic often mixes work that must run with work that can slip. You can now mark a **service line** as mandatory in its own right. Open the service line, tick **Mandatory service line**, save. The flag combines with the instance-level setting rather than replacing it. If either says mandatory, the session is mandatory. *Changed in v1.8.3: there was a third source — the clinic — and unticking the box on a service line would not make its sessions optional while the clinic was marked mandatory. Clinics are gone, so this NARROWS what counts as mandatory: 5 service lines qualified via a clinic where only 2 carry the flag themselves.* If a session is still mandatory after you untick the service line, the flag is on the session itself — open that session and clear it there. Both sources are OR-combined, so clearing one never clears the other. ### What "mandatory" actually does It does **not** force the roster to fill the session, and it will never cause a roster to fail to generate. The scheduler treats mandatory sessions as very strongly preferred: it will sacrifice a great deal of other optimisation to fill them. If it genuinely cannot — nobody with the right competency is available — it produces the roster anyway and reports the session as unfilled. This is a deliberate choice. A hard rule would mean one unstaffable session produces *no roster at all*, which helps nobody. Instead you get a roster you can work with, plus three things that make the gap impossible to miss: 1. **A red banner on the roster** listing every unfilled mandatory session — service line, date, and position. 2. **An audit event** (`roster.mandatory_unfilled`) recorded whenever a roster is published with gaps, so the decision to publish anyway is on the record. 3. **A tile on the cycle coverage page** showing how many mandatory sessions are unfilled. The intent is that publishing a roster with unfilled mandatory work is always a conscious act. ### What you'll see If everything is filled, nothing changes — the banner only appears when there is something to report. ## Equipment: one item, one place at a time Mobile equipment — echo carts, ECG trolleys, anything shared between rooms — is recorded with a pool size. The scheduler has always respected that pool, but it used to count usage per *slot*, which meant a fleet of two carts could in principle be allocated to three sessions running simultaneously in the same morning if those sessions sat in different slots. The scheduler now counts equipment usage per **daypart** — morning, afternoon, out-of-hours — so the pool size is respected across everything happening at the same time. Fixed (room-bound) equipment is unaffected: it was already handled by only offering rooms that have the kit. You do not need to change anything for this. Existing equipment records work as they are; the constraint is simply now correct where it previously had a gap. ## Maintenance schedules Equipment items can now carry a service schedule. Open the equipment item and use the **Maintenance schedule** tab to record: * **Service every (days)** — the interval. Weekly is 7, annual is 365. * **Last serviced** and **Next due** — both optional. * **Notes** — free text, up to 500 characters. The equipment list shows the next-due date in a **Next service** column, with the date highlighted in red when it has passed. The tab label carries a warning symbol for overdue items so you can spot them without opening each one. Each item has one schedule. Saving again updates it rather than creating a second entry, and clearing a field empties it. ### Be clear about what this does not do — yet This is a record, not a system. In this release: * Nothing sends you a reminder when a service falls due. * Nothing stops an overdue item being scheduled into sessions. * Nothing reserves time for the service itself. The dates sit there so you have them in one place, and so the scheduled-maintenance work planned for a future release has real data to build on rather than starting from an empty table. If you need reminders today, keep using whatever you use now — this does not replace it. ## What's coming next Planned for v1.7.9 and beyond: * Reminders when a service falls due, and the option to block an overdue item from being scheduled. * Maintenance windows the scheduler works around, so servicing does not collide with clinics. * Multiple schedules per item, for kit needing both an annual safety test and a monthly clean. * Live alerts on unfilled mandatory sessions, rather than only the on-screen banner and the audit record. * An unfilled-mandatory *rate* on the coverage tile alongside the current count. --- # 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/equipment-mandatory-and-maintenance.md?ask=&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.