Everything RadCalendar does, explained properly.

RadCalendar has a handful of building blocks that depend on each other. Setting them up in this order means you never hit a "there's nothing to pick" dead end.

1. Sites & Workplaces — create the actual location(s) staff get rostered into. Everything else (shift types, home base, roster assignments) hangs off a workplace, so this comes first.
2. Capabilities(optional at this point) — the shared skill vocabulary shift types and staff are checked against. You can set these up now on the Capabilities page, or skip ahead and add them inline the first time you build a shift type that needs one — whichever's less friction.
3. Shift Library — inside each workplace, define the actual shift types (Early CT, Late Ultrasound, etc.) with their times, how many people they need, which days they run, and what capability they require. Shift types must belong to a workplace, so step 1 has to exist first.
4. Staff— add people one at a time or via bulk import, then open each one's staff card to tick their capabilities, set a priority ranking, an FTE target, and any fixed day rules. Ticking a capability only makes sense once step 2's list exists.
5. The roster itself — with workplaces, shift types, and staff all in place, the roster calendar can actually offer something to assign into every cell, and the suggestion engine has enough information (capabilities, targets, constraints) to produce useful candidates rather than an unranked staff list.

Why this order specifically

Each step is a prerequisite for the data entry in the next one to be anything other than tedious guesswork: you can't pick a workplace for a shift type that doesn't exist yet, you can't tick a capability that hasn't been named, and the roster calendar's "Suggest" scoring is only as good as the capabilities/targets/constraints you've already told it about on each person's staff card.

Found in the "Sites & Workplaces" card on your main manager dashboard.

What's the difference?

• A siteis purely organisational — a physical building, e.g. "Footscray Hospital". It doesn't get shift types or roster entries of its own; it's just a folder for grouping workplaces.
• A workplaceis the actual assignable/schedulable unit — e.g. "Footscray Ultrasound". Shift types belong to a workplace, and every roster assignment is (workplace, day, shift type). This is the thing that actually matters for rostering.

Sites are optional

A workplace doesn't need a site — leaving one "ungrouped" is completely fine and common for a small single-location organisation. The Ungroupedsection is always shown and can't be deleted; it just holds any workplace that isn't filed under a site.

Adding one

Use the "Add site" or "Add workplace" mini-forms at the bottom of the card. A new workplace can optionally be filed under an existing site right away, or left ungrouped and moved later.

Reordering and moving (drag-and-drop)

• Drag a workplace card onto a site's card (or onto "Ungrouped") to file it there.
• Drag a site's header (the name/rename row at the top of its card) onto another site's card to reorder sites relative to each other.

Renaming and deleting

Both sites and workplaces rename inline — type in the small text field next to the name and it saves automatically (you'll see a brief "Saving…" / "Saved" indicator). Deleting a site ungroups its workplaces rather than deleting them; deleting a workplace removes it and its entire shift library— you'll get a confirm prompt naming the workplace before this happens.

Capabilities are the shared vocabulary that shift requirements and staff skills are matched against — things like CT trained, Ultrasound trained, X-ray trained, or Cath Lab trained.

Two ways to create one

• Up front, on the dedicated Capabilities page (linked from the main manager nav) — a simple list where you can add, rename, or delete capabilities for your whole organisation.
• Inline, while building or editing a shift type— the "Required capabilities" section of the shift type form has its own "+ add capability" box right there. Type a name and press Add (or Enter) and it's created and ticked for that shift type immediately — no need to leave the form or set anything up beforehand.

Both paths write to the same organisation-wide list, so a capability created inline while editing a shift type shows up on the Capabilities page too, and vice versa. One difference: the inline box can only create top-level capabilities — it has no parent picker. To nest one under another, create it on the Capabilities page instead.

Sub-capabilities

A capability can be nested under a parent — "MSK Ultrasound" under "Ultrasound" — using the "Parent capability (optional)" picker when you create it. The list then renders as an indented tree, and nesting can go more than one level deep.

The rule this buys you: holding a sub-capability counts as holding everything above it. Someone ticked for "MSK Ultrasound" alone is eligible for a shift requiring "Ultrasound", without needing both ticked. This applies consistently wherever eligibility is decided — the suggestion engine, auto-fill, the write-time check when you actually assign someone, and the conflict re-check on existing assignments. Ticking a parent in the roster's capability filter matches its descendants too.

A parent capability is otherwise an ordinary capability in its own right — you can require it on a shift type and tick it on a staff card directly, and doing so says nothing about the children.

Where capabilities get used

• On a shift type, as a requirement — see Shift Library.
• On a staff member's card (Rostering tab), ticked as something they have, with an optional priority rank if they hold more than one.
• Feeding the roster's suggestion scoring — a candidate's best-ranked matching capability earns them the "top-ranked skill" badge tag.

Each workplace has its own Shift Library — reach it from "Shift library →" on that workplace's card in Sites & Workplaces. This is where you define the actual shift types staff get rostered into.

Fields on a shift type

• Shift name— e.g. "Early CT".
• Start / End— the shift's time range; the library also shows the calculated hours next to each shift.
• Colour— used as the background colour for that shift's pills everywhere on the roster calendar, so you can tell shift types apart at a glance.
• People needed— how many staff need to be filled into this shift simultaneously. Once that many are assigned, the roster grid marks the row "Full (n/n)" and stops offering an empty slot.
• Required capabilities — tick any capability a person must have to be considered an eligible match for this shift (see the Capabilities topic for how to add one inline right here, without leaving the form).
• Shift period— Morning, Day, Evening, Night, or Other. Two things read this: the roster filter bar's "Shift period" dimension, and the time-of-day continuity rule, which uses it to spot someone being bounced between periods too often (see Match Settings).
• Training shift — a checkbox. On a shift flagged this way, someone with an active training assignment for a required capability counts as having it, and auto-fill deliberately leaves these slots until last. See Training assignments.
• Minimum staff level — None, Trainee, Qualified, or Senior. When set, anyone below that level is excluded from suggestions for this shift. An unsetStaff level on a person's card is not a wildcard — it fails every level requirement. This gate is independent of capabilities and of training: being in training for the right capability doesn't help someone clear it.
• Allowed days — a 7-day checkbox row (all ticked by default). Only the ticked days show this shift type as an option on the roster grid for that day of the week at all.

Adding and editing

Use the "Add shift type" form at the bottom of the page to create a new one. Each existing shift type has an "Edit" disclosure — click it to reveal the same fields pre-filled; changes here autosave as you type or as soon as you change a field (blur or change event), with a live "Saving…" / "Saved" indicator — there's no separate save button to remember to click.

Deleting

Each shift type has its own "Delete shift type" button with a confirm prompt naming it — this cannot be undone.

The other two sections on this page

Below the shift types themselves, the same page holds two features with their own topics:

• Coverage groups — for an area that can be staffed one of several alternative ways, with one option chosen per day.
• Blackouts — taking the workplace, or one shift type at it, out of service for a date range.

A coverage group says "this area can be staffed one of several ways, and we pick one per day" — e.g. MRI run either as one long shift or as an early/late pair, but never both. Managed from the "Coverage groups" section on a workplace's Shift Library page.

Groups and options

A groupis just a name ("MRI Coverage") belonging to one workplace. Inside it you add two or more options, each of which has:

• Option name— e.g. "Option A".
• Priority — a number, lower wins. This is the fallback preference, not a hard ranking; see below for exactly when it's consulted.
• Allowed days— which days of the week this option is even a candidate on. A day no option allows is a "gap day": the group contributes nothing and those shift types simply don't appear.
• Shift types— which of the workplace's shift types this option puts into play. A shift type that isn't in any option behaves exactly as it always has, unaffected by all of this.

How a day gets decided

Only one option is "active" per group per date, and its shift types are the only ones from that group that get rows on the grid. The choice is made in this order:

• A choice already recorded for that date — a manager's override, or a previous auto-fill run's resolution — always wins.
• If any of the group's shift types already has someone rostered that date, no choice is forced: every candidate option's shift types are shown, so existing work isn't hidden.
• Otherwise, when auto-fill runs it trial-fills each candidate option, discards any it couldn't staff completely, and picks the one with the best total candidate score — falling back to lowest priority number only to break a tie. If no option can be fully staffed, none is chosen and the day is left alone.

The badge, and overriding by hand

Each cell covered by a group shows an indigo badge reading "MRI Coverage · Option A". When more than one option is a candidate that day, the badge carries a dropdown — pick a different option and it takes effect immediately for that date only, replacing whatever was resolved before. A group with only one candidate option that day shows the badge with no dropdown, since there's nothing to switch to.

A blackout takes a workplace, or one shift type at it, out of service for a date range — scanner servicing, a ward closure, a public holiday. Managed from the "Blackouts" section on a workplace's Shift Library page.

Adding one

• Scope— either "— Whole workplace —", which blacks out every shift type there, or a single named shift type, leaving the rest of the workplace running normally.
• Start — the first date affected.
• End (optional) — the last date affected, inclusive. Leave it empty for a single-day blackout.
• Reason— free text and optional, e.g. "MRI servicing". It's shown to managers on the roster grid, so it's worth filling in.

On the roster grid

A blacked-out shift type doesn't vanish from its cell — it renders as a plain, greyed row reading "Blacked out until {date} — {reason}." with no "+" button and no Suggest button. The point is that a manager can see why there's no coverage there, rather than wondering where the shift went.

Tick Blacked out only in the Filters panel to see just these rows across the week.

It is refused, not just discouraged

Auto-fill skips blacked-out slots entirely and won't propose anyone for them, and coverage-group resolution is blackout-aware too. Manual assignment is now refused as well — assigning, moving or handing over into a blacked-out shift is rejected with the blackout's end date and reason, whether you go through an assign form, the move and replace controls, or by dragging a chip onto it. There is no "assign anyway" override: unlike a double-booking, a blackout usually means the room or the scanner physically isn't there.

The roster calendar (Roster calendar → from the main dashboard) is a grid: rows are workplaces, columns are days. Each cell can hold several shift rows, one per shift type allowed on that day.

Week, Month, Year zoom

The Week / Month / Year tabs at the top switch how much you see at once. In Month view, each day cell shows an "n/m filled" count and is a link — clicking it jumps straight to the Week view for the week that contains that day. In Year view, each month tile shows how many shifts are filled that month overall and links to that month's Month view. Only Week view lets you actually assign, unassign, or drag anything — Month and Year are read-only overviews for navigating.

Month and Year each have a second tab beside the zoom tabs: Roster (the fill counts described above) and Coverage, which instead shows whether each day's remaining seats could actually be staffed — see Coverage view. The "m" in "n/m filled" counts only the shifts genuinely running that day: where a coverage group offers alternatives, just the one option in play is counted, not all of them.

Getting to a particular week

← Prev week / Today / Next week → step a week at a time. The date boxbeside them jumps anywhere in one go: pick any day and you land on the Mon–Sun week containing it — you don't have to pick the Monday yourself, and you no longer have to detour through Month view to reach a week months away. Whatever the week resolves to, the box then shows that week's Monday.

The jump keeps whichever of Workplace or Staff view you were in. The same box sits on the staff-facing roster too.

Reading a shift row

Each shift row shows the shift's name and time range. Once every slot is filled it adds "Full (n/n)" — n filled out of n needed — and stops offering an empty-slot button.

Three other things can appear in a cell, each with its own topic:

• An indigo coverage-group badge ("MRI Coverage · Option A") naming which alternative staffing plan is active that day, with a dropdown to switch it.
• A greyed blackout row, showing a shift that's out of service and why.
• A red ring and ⚠ on an assigned pill, meaning that existing assignment now breaks a rule — see Conflict warnings.

Narrowing what you see

The "Filters" button above the grid collapses the week down by capability, site, workplace, shift period, coverage group, or current state (conflicted / blacked out / training shifts). It never changes the roster itself — see Filtering the roster. The workplace column and Monday–Friday stay pinned in place as you scroll sideways to the weekend.

Assigning someone

• Click the dashed "+" button on an empty slot to open a quick-assign picker. It defaults to a scored, eligible-candidates-only list with a score badge on each option (see Suggestions & auto-fill). Ticking "Show everyone" drops the scoring and lists every staff member instead — that's how you reach someone the suggestion engine has excluded (marked always-off, fixed elsewhere, opted out of auto-match, no logged availability, below the shift's minimum staff level, or off-pattern). It is not a capability bypass — see below.
• The "✨ Suggest" button (next to any slot that still has room) opens a ranked shortlist of the top few candidates for that specific slot — pick one to assign directly from the list.
• If a "↻ name" suggestion chip appears under a shift row, that person has this exact workplace/shift/day set as a Usual Pattern on their staff card — click it to assign them in one step.

Moving and unassigning

Drag any assigned pill to a different shift row, day, or workplace cell to move that person there — the grid updates immediately. Click the × on a pill to unassign that person from that shift entirely.

Double-booking warning

Assigning or moving someone who's already rostered elsewhere that same day shows a warning naming the conflicting shift — "Already assigned to {shift} on {date}. Assign anyway?" — confirming proceeds and creates the double-booking deliberately; cancelling leaves things as they were.

Capability requirements are enforced

A shift type's required capabilities are a hard rule at the moment of assignment. Assigning or dragging someone who doesn't hold one is refused outright— you get "Missing required capability: {name}." and nothing is written. There is no confirm-and-proceed override, and no picker setting that gets around it. To roster that person, either tick the capability on their staff card or drop the requirement from the shift type.

Two things count as holding the capability:

• A sub-capabilityof the one required — someone cleared for "MSK Ultrasound" satisfies a shift requiring "Ultrasound". See Capabilities.
• An active training assignmentfor that capability — but only on a shift flagged "Training shift". See Training assignments.

Other write-time refusals

Two more rules are enforced the same way, regardless of what the picker showed you: a shift that already has everyone it needs ("This shift is full (n/n)"), and minimum rest when it's set to Hard in Match Settings. Double-booking is the one genuine override — it warns and lets you confirm.

A second way to look at the same week: the "Staff" tab next to "Workplace" at the top of the roster calendar pivots the grid so staff are the rows and days are the columns, instead of workplaces. Same underlying assignments, same filters, same drag-and-drop — just a different angle for when you're thinking about one person's week rather than one workplace's coverage.

Rows and grouping

Staff are grouped the same way as the Manager page's staff list — by group and subgroup, in the order you've set them there, with an "Ungrouped" section last. A bank or agency staff member gets a small "Bank" or "Agency" badge next to their name. The second line under each name is their home base workplace, purely informational — it doesn't limit which workplaces they can be assigned to here.

Reading a cell

Each cell holds a flat stack of small chips, one per assignment that person has that day — a chip shows the workplace and shift type, colour-coded the same as Workplace view. Someone working two different workplaces the same day just gets two stacked chips in that one cell.

Assigning, moving, unassigning

• Click the dashed "+" in any cell to assign — since the person is already fixed by the row, this form asks for a workplace, then (once chosen) a shift type at that workplace allowed on that day.
• Drag a chip to a different day in the samerow to move that assignment's date, keeping the workplace and shift type unchanged.
• Drag a chip onto a differentperson's row to reassign it to them — the workplace and shift type carry over from the dragged chip, whether the target cell is empty or already has chips of its own. The same double-booking and capability-mismatch checks from Workplace view apply.
• Click the × on a chip to unassign that person from that shift entirely, same as a pill in Workplace view.

Filters carry over between views

The Filters panel and the week you're viewing are both kept when you switch the Workplace/Staff tab — neither resets. In Staff view the filters never remove a person: every row stays on screen and the assignments that don't match are dimmed. Filtering by a capability shows you where your CT people are relative to everyone else, which is usually the question a staffing view is being asked. See Filtering the roster.

Searching for one person

The search box above the grid narrows the rows to staff whose name matches what you type — matching anywhere in the name, not just the start, and ignoring case. It's the quickest way to get to one person's week when you know who you're looking for, since the Filters panel deliberately has no name dimension of its own.

The search is the only thing that removes a row — the filters dim, the search hides. The two stack without interfering: searching narrows to the people whose name matches, and the filters then dim whichever of their assignments don't qualify. Clearing the search leaves your filters alone, and vice versa. If the search matches nobody you get an explicit line saying so rather than a blank grid, and if the filters match nothing all week you get a line saying that too — otherwise a grid of uniformly faded chips would look like a fault rather than an answer.

Searching only changes which rows you see, never their order — the group and subgroup ordering described above holds exactly as it does unsearched.

What Staff view doesn't have

This view is for arranging one person's week rather than for filling gaps, so several Workplace-view tools aren't here at all: no "✨ Suggest" button, no score badges, no usual-pattern chips, and no auto-fill. Use Workplace view when you're trying to cover a slot and want the engine's opinion.

The assign form is simpler than Workplace view's in one way worth knowing: it lists every shift type allowed at that workplace on that day, without checking whether the shift is already full or blacked out. Choosing a full one is refused after you click Assign, with "This shift is full (n/n)".

The Month and Year views have a second tab, "Coverage", that answers one question per day: can everything still unfilled actually be staffed by someone who is qualified and free? It looks months ahead, so it's where leave, blackouts and thin capabilities show up before they become this week's problem.

The three states

• Covered — every remaining seat can be filled, with someone spare.
• Critical cover (amber) — every seat can still be filled, but at least one person is irreplaceable: if any one of them became unavailable, the day would be short. The number is how many such people there are. These are the days worth looking at before someone calls in sick.
• Short (red) — some seats cannot be filled at all. The number is how many.

Colour is never the only signal — every day also carries its count, and hovering any cell spells the situation out in a sentence.

What "covered" actually means

It means a legal assignment exists. It does not mean a good one. The check counts a person once, no matter how many capabilities they hold — someone signed off on CT, MRI and X-ray can cover one of three concurrent shifts, not three — and it accounts for capability (including sub-specialties), staff level, approved leave, always-off days, fixed workplace and start time, and bank/agency availability.

It deliberately ignoresminimum rest, night blocks, time-of-day continuity, shift patterns and FTE targets. So a day marked covered might only be coverable by an arrangement you'd never actually make. Treat it as a floor — the day is not impossible — rather than a prediction of what auto-fill will produce.

What it already knows about

• Seats already filled are taken off the list, and the people filling them are no longer counted as available. So the picture improves as you build the roster.
• Approved leave removes that person for those dates.
• Blackouts remove the seats, so a workplace closed for servicing reads as no demand rather than a fortnight of shortfall.
• Bank and agency staff only count on dates logged on their Availability list. If nobody has logged any, they are invisible here — which will make the picture look thinner than it is.

Coverage groups on days nobody has decided yet

Where a coverage group has several options and no choice has been made for a future date, this view assumes the highest-priority option runs. Auto-fill may later pick a different one after actually comparing them, so the two can disagree on unresolved days. That is deliberate: comparing options properly costs a full scoring pass per option per day, which is not something a twelve-month view can do.

The "Filters" button above the roster grid opens a panel of eight dimensions for narrowing what the week shows. It's collapsed by default; once anything is active the button reads "Filters (3)" so you can tell at a glance that what you're looking at isn't the whole picture.

The five value pickers

• Capability — shown as an indented tree. Ticking a parent also matches its sub-capabilities, so filtering to "Ultrasound" keeps shifts that require "MSK Ultrasound" too. See Capabilities.
• Site— hides whole workplace rows that aren't filed under a ticked site. A workplace with no site is hidden whenever any site is ticked.
• Workplace — the same, one workplace at a time.
• Shift period — Morning / Day / Evening / Night / Other, the setting on each shift type in the Shift Library.
• Shift group — shift types belonging to a named coverage group. See Coverage groups.

The three state toggles

Below the divider, three checkboxes filter on current state rather than on a shift type's fixed properties:

• Conflicts only — only shift rows holding an assignment that currently fails a matching rule. See Conflict warnings.
• Blacked out only — only blacked-out rows. This one wins outright: nothing assignable is shown alongside it, since a blacked-out row has no assignments to compare against anyway. See Shift blackouts.
• Training shifts only— only shift types flagged "Training shift". See Training assignments.

How they combine

Every active dimension is ANDed — a row has to match all of them, not just one. Ticking several values withinone dimension is an OR (any of the ticked capabilities, any of the ticked sites). "Clear all" in the panel header resets every dimension at once.

Filtering never changes the roster

This is display narrowing only. A shift type you've filtered out of view is still real, still assignable, and still counted — nothing is unassigned, and a filtered-away shift doesn't start showing its existing entries under "Not allowed on this day". Auto-fill also ignores your filters completely: it scores every empty slot in the week regardless of what's currently on screen.

Shared between Workplace and Staff view

The filter panel sits above the grid rather than inside it, so switching the Workplace/Staff tab keeps every active filter. The two views apply them slightly differently, because their rows mean different things:

• In Workplace view, site and workplace hide whole rows; the rest hide individual shift rows inside a cell.
• In Staff view, every dimension is judged per assignment and no dimension ever removes a person. Every row stays and the non-matching chips are dimmed. The rule is the same one Workplace view follows — a filter naming the row's own identity hides, anything else narrows what is inside it — and a Staff-view row's identity is the person, which only the name search addresses.

The suggestion engine checks its rules when you're choosingsomeone. This checks them again afterwards, on assignments that already exist — so a roster that was fine when it was built doesn't quietly stop being fine when something else changes underneath it.

What you'll see

Any assignment that currently fails a rule gets a red ring and a ⚠ marker on its pill (Workplace view) or chip (Staff view). Hover it to read the reasons — there can be more than one. Nothing is moved, unassigned, or changed for you; it's purely a flag for a human to deal with.

What gets re-checked

• Missing a required capability.
• Below the shift's minimum staff level.
• Marked always-off that day.
• Fixed to a different workplace that day.
• Fixed to a different start time that day.
• Already rostered on another shift that day.
• Breaks minimum rest — flagged in both soft and hard mode, unlike the suggestion engine where soft mode is only a score penalty.
• Breaks time-of-day continuity — only when that rule is switched on in Match Settings.
• Doesn't match this week's shift pattern.
• Spread across too many modalities or workplaces this window — only when Placement continuity is switched on.
• Extends a night block too far, or starts one before the cooldown has passed — only when Night blocks is switched on, and only on shifts whose period is Night. Like minimum rest, this is flagged in both soft and hard mode.

Sub-capabilities and active training assignments are honoured here exactly as they are at assign time, so a trainee legitimately rostered onto a training shift doesn't read as a false capability conflict.

Everything on this list is advisory. Setting a rule to Hard changes who the suggestion engine will offer you; it makes no difference here. An existing assignment is flagged either way, and is never moved or removed for you.

What it deliberately doesn't check

Blackouts, the per-staff auto-match opt-out, and bank/agency availability are not re-checked. Those govern who gets offereda slot, not whether an existing assignment is wrong — a manager who deliberately rostered someone outside their logged availability shouldn't be nagged about it every week.

Finding them

Tick Conflicts only in the Filters panel to reduce the week to just the conflicted rows — the practical way to work through them after changing a capability, a constraint, or a Match Settings rule. See Filtering the roster.

Short free-text notes pinned to a day on the roster grid — the things that aren't an assignment but change how the day runs. "MRI 3 down until lunchtime", "covering reception till 2". Available in both roster views, on any cell.

Two anchors, and the difference matters

A note is attached either to a workplace and a date, or to a person and a date. Which one you get depends on the cell you add it from, and they behave differently:

• Workplace notes stay with the room. Added from a Workplace-view cell, they describe the place on that day — equipment down, a delivery arriving, a list running late.
• Person notes travel with the human. Added from a Staff-view cell, they follow that person wherever their shifts move, and they also reach them on their own staff page. Use these for anything about the individual rather than the location.

A thread, not one note per cell

Notes append rather than overwrite. A single cell can accumulate several unrelated facts on one day from different people, each stamped with its own author, newest last. Delete individual notes when they stop being true. This is deliberately unlike the standing description on a staff card, which is one evolving note about a person rather than a dated thread.

Notes are capped at 500 characters — the same limit leave requests use. They are meant to be read at a glance inside a dense grid cell, so the closed state is a single muted line.

Who can see them

Everyone in the organisation. Staff see roster notes for the week on their own page, the same way they see the roster itself. Notes are not private working memory — write them as though the person they concern will read them, because they can.

Taking someone off a shift keeps a record of it. Every assignment chip carries two controls: ⇄ hands the seat to someone else, and ↷ sends this person somewhere else. They answer different questions, and one event can be both.

Replace: someone else takes this seat

The outgoing person comes off, the incoming person goes on, and the two are linked. Every check a fresh assignment would face is run against the incoming person — capability, capacity, minimum rest, double-booking — so a handover can't slip through a gate a normal assign would fail.

Move: this person goes elsewhere

Pick a destination workplace, shift type and date. The date defaults to the one they are on and is editable, so the same control covers "moved sites at 11am" and "shifted to Thursday".

Dragging a chip onto another cell performs the same move. The form exists because the two gestures aren't interchangeable: a drag is a planning motion with nowhere to explain itself, while a real mid-shift move is an operational record whose reason is most of its value. That reason is the only thing the form adds — it becomes a person-anchored roster note on the day they moved, which also reaches them on their own staff page.

What the struck-through chips mean

A superseded assignment stays in the cell, greyed and struck through, with a suffix saying where it went:

• Sam → Priya — someone else took this seat.
• Sam → Ultrasound (Riverside) — Sam went to another shift. The move names the destination shift and its site, not a person, because that is the question a move raises.
• Sam → Priya, to Ultrasound — both at once: a cross-site swap.
• Sam · removed — neither. A plain unassign: leave approved, shift dropped, no successor.

Hovering a chip gives the same thing as a full sentence.

Removing is not deleting

Taking someone off a shift used to destroy the fact they were ever on it. It now marks the assignment superseded and leaves the row in place. The seat frees up exactly as before — every coverage count, capacity check and conflict check ignores superseded rows — but the history survives, and the roster can answer "who was on this originally, and what happened" weeks later.

Puts a specific person into timed training for a specific capability — "Josh is doing MRI training until 1 September" — rather than just tagging a shift "training" in the abstract. Lives in the Training section of a person's Rostering tab, near Capabilities. Only managers start, adjust, or cancel a training assignment — there's no self-service for staff.

Starting one

Pick a capability (only capabilities this person doesn't already hold, and isn't already actively training in, appear in the list), a start date (defaults to today), and a target end date, then click "Start training" — a deliberate button, not autosave, since starting is a real state change. A person can only have one active training assignment per capability at a time; to change what they're training in, cancel the old one first and start a fresh one for the new capability.

What it does while active

A person with an active training assignment for capability X becomes eligible for shifts flagged "Training shift" (Shift Library) that require capability X — shown in Suggest/the picker with an "in training for this capability" tag — even though they don't hold X yet on their Capabilities list. This is narrow and doesn't leak anywhere else:

• It onlyapplies to shifts explicitly flagged "Training shift." The same person is still excluded from an ordinary (non-training) shift requiring that same capability until it's actually granted.
• It does notbypass a shift's "Minimum staff level" — that's a separate, independent gate. Being in training for the right capability doesn't help if the shift also requires a staff level this person doesn't have set.

Auto-completion — becoming competent for real

There's no scheduled job checking dates in the background — instead, whenever this person's staff card is opened, or whenever the suggestion engine runs a scoring pass anywhere in the app, any of their training assignments whose target end date has already passed are completed on the spot: the capability is ticked for real on their Capabilities list, and the assignment moves to a "completed" history line. In practice this means it can take until the next relevant page load or suggestion request for a just-elapsed assignment to flip — not an exact-to-the-second background process, but close enough that it's never stale for more than a normal working session.

Once completed, the person is a completely ordinary, fully qualified candidate for that capability — for training shifts and ordinary shifts alike, with no more special-casing.

Extending or shortening

The target end date on an active assignment autosaves, same as every other date field in this app — just edit it directly. Push it further out to extend the training period (it won't complete early just because the original date has passed if you've already moved the goalpost), or pull it into the past to force it to complete on the next trigger, same mechanism as a natural expiry.

Cancelling

"Cancel" on an active assignment is a deliberate button, not autosave. It marks the assignment cancelled and does notgrant the capability — use this when training didn't work out, rather than just letting the date lapse.

History

Completed and cancelled assignments both stay visible under "History" on the staff card — capability, start/end dates, and whether it finished by completing or was cancelled. This doubles as a lightweight audit trail of how someone came to be marked competent in a capability, not just a tick with no context.

"Dashboard →" on the roster calendar opens the FTE/Hours Dashboard — a per-staff summary of who's unrostered, under target, or over target for the current period, plus a full breakdown table for everyone.

Leave requests come first

If anyone has asked for leave, their requests sit at the top of this page, above everything else — with the shifts they're already rostered on in that range, and Approve / Reject controls. That's the whole discovery mechanism, since nothing is emailed; a count also appears next to "Dashboard" on the roster calendar. See Leave and absence for how approving works.

The lists

• Unrostered — nobody scheduled at all this period. Staff with approved leave covering any part of the period are excluded from this list automatically; you can also record a leave block for someone directly from here.
• On leave — approved leave covers this person's entireperiod, so they aren't measured against a target at all. Without this they'd sit in "Under target" every period for the length of the leave, which for parental leave means months of noise. Partial leave doesn't land here — that still counts normally, with a note on the row saying why the numbers are low.
• Under target / Over target— compares actual hours or shifts against each person's FTE target from their staff card. Which of the two, and over what window, is set by your organisation's FTE calculation mode — see Match Settings. Over-target rows can be marked "Planned" with an optional note, so deliberate overtime reads as expected rather than a problem to chase up.

Below minimum

Separately from the under/over-target lists, anyone with a "Minimum shifts" floor set on their staff card (next to FTE target) shows a red "Below minimum" badge in the full breakdown table if their actual shift count in their own chosen period— Week, Fortnight, or 4 weeks, whichever they're set to — falls short. This is checked against that person's own period, not necessarily the same window the rest of the dashboard is showing (which follows your organisation's overall FTE mode) — so a weekly minimum is always checked against the current week specifically, even while the dashboard itself is displaying fortnightly figures for everyone else. It's purely a warning badge — never enforced by suggestions or auto-fill.

The summary strip

A counter row at the top of the page totals each list — unrostered, under target, over target (with how many of those are marked planned), and, when there are any, how many people are below their minimum shifts or on leave for the whole period. The subtitle under the page title tells you which window everything is being measured over, since that follows your organisation's FTE calculation mode.

"No target set"

Anyone rostered this period who has no FTE target on their staff card gets a grey No target setbadge in the breakdown table rather than being called under or over. That's a deliberate opt-out, not a problem — but it's also what you'll see for everyone whose target was filled in for the other FTE mode, so a sudden crop of them usually means the mode was switched rather than that targets were deleted.

Leave covers everything from a single sick day to nine months of parental leave — one concept, with a type on it. Staff request it from their own page; you approve or reject it on the FTE Dashboard, or record a block directly if it's already agreed. Once leave is approved, that person stops being suggested or auto-filled for those dates.

Where requests come from

• Staff request it— the "Leave" button on their roster page. They pick a first day (by clicking a calendar or typing it), an optional last day, a type from your organisation's own list, and can add a note. It arrives with you as pending.
• You record it directly on the leave calendar — click any empty square on Leave calendar (from your home page). This is the usual way to log leave you already know about, and it works for anyone whether or not they have shifts booked.
• You record it from the dashboard— "Mark as on leave" in the Unrostered list on the FTE Dashboard. Same effect as the calendar, but only offered for people with no shifts at all this period.

The leave calendar

Leave calendaranswers the question the dashboard doesn't: who is off, and when. One row per person, one column per day of the month. Filled green squares are approved leave; dashed amber squares with a ? are requests still waiting on you. Hovering any square names the person, the type and the full block it belongs to, so a single day off is distinguishable from month nine of a parental block.

Year gives twelve tiles with the approved days booked in each month and a bar to compare them at a glance — useful when someone asks for three weeks in a month that is already thin. Each tile opens that month.

Recording leave that overlaps leave already approved for that person is refused, naming the dates it collided with. Approving or rejecting a pending request still happens on the dashboard — the calendar shows pending squares so you can see what has already been asked for before you record something over it.

Finding out a request exists

Nothing is emailed or notified — RadCalendar has no notification system, deliberately. Instead a count appears next to Leave requests on your home page and next to Dashboard on the roster calendar whenever something is waiting. The requests themselves sit at the top of the FTE Dashboard.

This means you have to look. If a request is urgent, expect the person to tell you directly as well — the staff page says as much.

Deciding

Each pending request shows who, the dates, the type, their note, and the shifts they are already rostered on inside that range. Then:

• Approve and unassign — approves the leave and removes those shifts, leaving the seats open for someone else. This is usually what you want.
• Approve and keep them — approves the leave but leaves the shifts on the roster. Legitimate for voluntary cover or an on-call arrangement. Those entries then show up as conflicts (see below) so the situation is never silently inconsistent.
• Reject— records the decision. Nothing is excluded and no shifts change. Add a note and they'll see it.

Nothing is pre-selected — approving always takes a specific click on one of those buttons.

With more than one request waiting, a search box appears above the queue. It matches the requester's name, the leave type, the dates as they're written, and their note — so "priya", "sick" or "dec" all narrow the list. It deliberately does not match the affected shift names underneath. Searching only hides rows; the count in the heading stays the true number waiting, and the approve/reject buttons on a visible row are unaffected.

What the shift list does and doesn't tell you

The list of affected shifts is exact: it is precisely what that person would stop covering. It is nota coverage forecast. It doesn't check who else holds the right capability, or whether they're already booked, short on rest, off that weekday, over their FTE target, or blocked by a blackout or a night-block rule. For "can this actually be refilled", open the roster calendar for those dates and use Suggest.

What approved leave then does

• They are excluded outright from the assign picker and from auto-fill for every covered date — not ranked lower, excluded. There is no setting to soften this.
• In Staff view, each covered day shows a muted band naming the leave type instead of the "+" button.
• On the FTE Dashboard, anyone whose whole period is covered moves into an On leave list instead of being measured against a target they were never going to meet. Partial leave still counts normally against their target.

It gates suggestions, not manual assignment

Same limitation as blackouts, and worth knowing. Auto-fill and the assign picker will never offer someone on approved leave — but you can still put them on a shift by hand, by dragging a pill onto the day. The write goes through.

Unlike blackouts, though, this one is flagged afterwards: any entry sitting inside approved leave shows "Rostered during approved leave." as a conflict on the roster grid. That covers both directions — leave approved over existing shifts you chose to keep, and someone assigned onto leave later.

Setting up your leave types

The kinds of leave are yours to set, not a fixed list. Open Leave types from the leave calendar to add, rename, reorder or turn one off. A new organisation starts with seven — annual, sick, maternity/parental, unpaid, other, RDO and ADO — and you can shape that list however your service actually works.

• Turning a type off removes it from the request form for new leave. Everything already recorded under it keeps its name and still counts on staff cards — nothing is rewritten or hidden. This is what you want almost every time.
• Deleting is only offered for a type nothing has ever been recorded under. Once a single record uses it, delete stops being an option and you turn it off instead — so no leave record can ever be orphaned by tidying the list.
• The order you arrange them in is the order they appear in the request dropdown and in the per-type breakdown on a staff card.
• Renaming updates the wording everywhere at once, including on leave already recorded — records point at the type itself, not at its name.

Each type also carries a colour, and that is what approved leave is painted in — on the month and year calendars, in Staff view on the roster, and on a staff member's own page. Each calendar prints a key of just the types actually showing, so a colour never has to be memorised.

How much someone has had

The Leave section of a staff card (Rostering tab) opens with Approved days taken · last 12 months onwards: a total plus a per-type split. Only approved records count — pending and rejected ones sit in the list below it without ever being added in.

It is a rolling window with a floor but no ceiling. The floor is the date exactly 12 months back, named on screen so you can check it. Anything still running on or after that date counts, and leave you have already approved for future dates counts too — it is approved, the roster is planned around it, and hiding it until it happens would make the number jump for no visible reason.

A block that straddles the floor counts its whole length, not just the days inside the window. Someone who took three months off ending a week after the floor reads as three months, not one week. The figure is inclusive calendar days with no working-day adjustment, and the record list underneath is full history that ignores the window.

Fixing a mistake

A staff member can cancel their own request while it's still pending, but not once it's approved. You can delete any leave record from the Leave section on their staff card (Rostering tab). Deleting approved leave makes them assignable again straight away — but it does not put back any shifts that were removed when it was approved. Those are open seats now and need re-filling like any other.

You can't approve two overlapping blocks for the same person — it's refused, naming the dates already covered. Overlapping pending requests are fine, so someone can offer you two possible date ranges and let you pick.

A published contact list for out of hours: who to ring, and on what number. It lives at Manager → On-call rotaand is a separate schedule from the roster — being on call doesn't occupy a shift and doesn't change anybody's working week.

Lines, not slots

The rota is built from lines— "1st on-call", "2nd on-call", "Interventional on-call". Each line carries its own hours and holds exactly one person per night. If two people are on at once, that is two lines, not two names in one cell.

• Name — how the line is referred to on the floor. Rotas have a natural seniority order, so lines are shown in the order you arrange them rather than alphabetically.
• Hours — the window the line covers. An overnight line ending before it starts (17:00 to 08:00) is normal and expected here; it is read as running through midnight.
• Active — retiring a line stops it asking to be filled but keeps everything already assigned against it. A line with history behind it should be deactivated, not deleted.

Filling the grid

Lines run down, nights run across, a week at a time. Click a cell and pick somebody. A line doesn't have to run every night — leaving weekday cells empty on a weekend-only line is a normal state, not an unfilled gap demanding attention.

Contact numbers

Each person can carry two numbers, set on their staff card under Personal → Contact. They answer different questions at 2am: the mobileis the person, and the second number is wherever they are — home, a ward, a switchboard extension. Both are free text, so "Ext. 4471" and "0412 345 678 (after 8pm)" are both fine.

If anyone on the rota has no mobile on file, the page says so underneath the grid with a count.

What it deliberately does not do

• It is not the roster.On-call doesn't count toward hours or FTE targets, and doesn't stop someone being rostered normally that day or the next morning. If you want that protection, it is the roster's minimum-rest rule that provides it — see Match settings.
• Nothing is checked when you assign. No capability test, no rest test. The rota is a contact list, and you already know who is qualified to hold the pager.
• Everyone can see it.Staff see the whole organisation's rota and the numbers on it — that is the point of publishing one. Only managers can change it.

A register of university students on clinical placement, at Manager → Placement students. Students are not staff: they hold no account, never appear on the roster, and cannot be auto-filled. This register is the only place they exist.

Adding a student

• Name — the only required field. A register is worth keeping even when all anyone knows on the first morning is a name.
• University and cohort — optional, and what the university asks about when it wants a record back.
• Site — where they are placed. Optional, and set to a site rather than a workplace: students rotate around a building.
• Supervisor — the named radiographer responsible for them. This is a real link to a staff member, not free text, so it follows a rename and survives them changing workplace.
• Notes — up to 500 characters. Useful for the thing the next person on shift needs to know: what they are signed off for, what they must not do unsupervised.

Placement days are counted, not estimated

Each day a student attends is recorded individually, so the total is exactly the days attended rather than a span with weekends guessed out of it. Universities ask for a number and it has to be right.

Adding them one at a time would be miserable, so days are added a range at a time — pick a start and an end, optionally weekdays only, and the range expands into individual days. Re-adding an overlapping range is safe: it adds only the days that were missing, so extending a placement never double-counts. Remove the odd day when somebody is off sick.

Archiving

When a placement finishes, archivethe student rather than deleting them. Archiving keeps the day count for the university's records and takes them off the current list. The page header toggles between Current and Archived, each with its own count.

Who can see this

Managers only. Staff — including a student's own supervisor — have no access to the register at all. It is administrative record-keeping about people who are not members of the organisation, and it carries a free-text notes field, so it is not published the way the roster and the on-call rota are.

New accounts are created with a temporary password — one you choose when adding someone individually, or a fixed shared one when importing in bulk — and every account is forced to replace it before it can be used properly.

Where the first password comes from

• Adding one person at a time— you choose their temporary password on the "Add staff member" form. Minimum 8 characters.
• Bulk import— you don't get to choose. Every imported account is created with the same fixed temporary password, Today1234!, and there's no field on the import page to change it. Everyone imported in a batch therefore shares a password until they each sign in and replace it, so it's worth importing and onboarding in reasonably prompt succession rather than months apart.

The forced-change gate

However the account was created, the first time they sign in (or any time this flag is still set), they're redirected straight to a "Set a new password" screen and can't reach the roster or anything else in the app until they've chosen their own password (minimum 8 characters, entered twice). This check runs on every page load while the flag is set, not just once at login, so it can't be bypassed by navigating directly to a different page.

Resetting a password later

• "Reset password" on the Staff list— generates a brand-new random temporary password and shows it to you exactly once, in an on-screen box with a Copy button — pass it on to that person now, since it's never shown again and never logged anywhere.
• "Reset password" on the staff card's Personal tab — a shortcut that resets straight to the shared default temporary password (Today1234!) instead of generating a random one — handy when you'd rather not have to relay a one-off password out of band.

Either way, the account's current password stops working immediately and the forced-change flag is set again, so the person is walked through "Set a new password" on their very next sign-in.