Scheduling
Scheduling has two halves. The calendar is where events are seen and arranged; the setup pages decide what a valid schedule is — which events exist, what rules they must satisfy, who those rules apply to, and when people are available at all.
Where to find it
| Screen | Where it lives | What it is for |
|---|---|---|
Schedule — /schedule | the sidebar | the whole calendar |
My schedule — /my-schedule | the sidebar | the same calendar, showing only events you are on |
Scheduling setup — /admin/scheduling | Settings → Work & scheduling → Scheduling setup | event types, rules, profiles, budgets, places, requests |
Calendars — /admin/scheduling/calendars | Settings → Work & scheduling → Calendars | working hours, dated exceptions, publishing, external links |
Recurring series — /admin/scheduling/series | Settings → Work & scheduling → Recurring series | a repeating event and its exceptions |
The calendar
Day, Week, Month and Agenda views, with Today, Previous and Next. Filters narrow what you see: by Types, by Resource (a person or a thing, or Everyone), by Status, or by a title search. Show 24 h opens the whole day rather than working hours, and Print gives you a printable copy.
New events as picks the type a new event is created with, or leaves it on First matching type.
The dispatch tray holds events waiting to be placed.
My schedule is the same page with one thing changed: only events you are a participant on. If you do not have permission to see the whole schedule, this is the one you use.
Scheduling setup
The setup page is organised in tabs.
Event types
What kinds of event exist. Each type carries:
| Setting | What it means |
|---|---|
| Default duration | minutes, for a new event of this type |
| Roles involved | who is on the event |
| Seat capacity | for a group event |
| Counts as busy | whether it blocks other events |
| Others see only "busy" | hide the detail from people not on it |
| Arrival window | how much slack there is around the start |
| Customer sees the exact time | or only the window |
| Open-shift claiming | whether workers may claim it |
| Participants must acknowledge changes | a change is not settled until they do |
| Confirm-link wording | what the Confirm / Cancel / Request-reschedule links say |
| Job blueprint to spawn | the work item blueprint an event stamps out |
| Budget service key | which authorisation budget it draws from |
| Pinned rule profile | a profile that binds for every event of this type |
| Colour | how it reads on the calendar |
Constraints — the rules a schedule must satisfy
A rule is one requirement: a gap, a maximum, a qualification, a limit. Rules live in profiles, and a profile says who it governs using the same filter grammar views use.
Profiles are ordered, and the order is the tie-break: when two profiles match the same person and set the same rule differently, the one higher in the list wins — unless a recorded override says otherwise.
Hard blocks are never softened
Some rule types can only ever be a hard block, never a warning. Those are listed under Hard-block-only types, and the list is honest about what it is for: a block of those types is never softened by list order and never softened by an override. The page will tell you why it can never be a warning for each entry.
Global entries in that list are shared; a space row extends the list, and a disabled space row lifts a global entry here.
The collision check
Before you save a profile, press Check collisions. It is checked live, over the people who are actually schedulable right now, and it reports in those terms:
would match 34 of 120 schedulable people · 3 open collision(s) · 1 hard-floor line(s)
A collision is two profiles matched to the same person setting the same rule differently. The dialog shows the picture and asks you to decide before saving: confirm the list order (and it says which profile wins), or record an override with a reason. The reason is kept on the collision picture. Save anyway is offered as an explicit, audited dismissal — never as a silent one.
Hard floors are listed separately, because they are not up for negotiation.
Budgets
An authorisation budget is a quantity of service a client is authorised to receive: a total, a unit, a period, an optional sub-cap (a maximum per week or per month inside the period), and a warn at %. Events of a type that names the budget's service key draw it down, and a group event can be set to draw once or once per attendee.
Budgets can be adapted from authorisation rows already on a client's contact: load the authorisations, preview the mapping, then adapt. It is one-way and one-time — the result is a set of ordinary budget rows you then own and edit; the origin is a record of where they came from, not a live link.
Places and travel
Name the places events happen at, and then the travel minutes between places: consecutive events at different places need at least that gap. A pair with no row uses the space default.
Requests
Worker requests — shift claims, swaps, availability changes, time off — and customers' reschedule asks wait here for a decision. Approving applies the change through the ordinary doors and constraint gates, so an approved request cannot create a schedule the rules forbid. The open-shift board below lists events published for claiming.
Bundles
As with work items, a bundle is a seeded starting point — event types, rules, profiles with their seeded resolutions, workflows and settings. Apply turns them into ordinary rows of your space, keeping anything already present.
Bundles also install workflows, and those get two extra controls:
- Repair installed workflows — any installed copy whose graph or trust class no longer matches its template is re-cloned fresh; the old copy is retired with its history kept, and copies that already match are left alone.
- Uninstall workflows — every workflow the bundle installed is retired and its triggers silenced. Event types, rules, profiles and settings stay: they are ordinary rows of your space now. Re-applying installs fresh copies.
Calendars: when people are available
| Panel | What it holds |
|---|---|
| Working hours | the ordinary week, per day, with Closed all day where that applies |
| Dated exceptions | one date that differs — a holiday, a late opening. An exception can also start on the eve at a given time |
| Calendar system | the calendar the dates are read in, with its leap policy, time zone and slot minutes |
| Display calendar | which calendar the schedule is drawn in |
| Require publishing before display | a schedule is not shown until somebody publishes it |
| Automatically send change notices | participants are told when their event changes |
| External calendar link | link an outside calendar, with its Health and Error streak shown, and Pause sync / Resume / Unlink |
A space default applies where a calendar has no value of its own.
Recurring series
A series is a recurrence: a rule, an event template, a start and an end. Create one, edit it from now on, or end it with Set end date. Cancel series cancels it and its future occurrences, after confirming.
The thing to understand about editing a series is what happens to occurrences somebody has already changed by hand. When you save a change, the page shows a review: keep or regenerate list of every future hand-edited occurrence:
- leave an occurrence KEEPed and its hand edit survives;
- clear the tick and that occurrence is regenerated from the new rule.
Regular, un-edited future occurrences are regenerated without asking — the page says how many. Afterwards it reports exactly what it did: regenerated 12; kept 2; canceled 0.