Booking-level restrictions in the Scheduling Operations Agent

Status: Public Preview — behaviour may change.

What it does

Two per-booking fields — Optimization behavior and Restrict to — let a dispatcher override how the Scheduling Operations Agent treats one individual booking, instead of accepting whatever the booking's status-level optimization method implies. Everything else in the run still obeys the goal, the scope and the status methods; only that booking behaves differently.

Key facts

Optimization behavior has four values. Ignore leaves the booking alone but lets the agent schedule other work over the top of it. Optimize is the default and lets the agent move it freely within its constraints. Schedule if feasible guarantees the booking stays on the schedule if a feasible solution including it exists. Do not move freezes resource and arrival time even when the placement breaks constraints.
Do not move is effectively the same as setting Restrict to = Resource + Arrival time. Two routes to the same outcome.
Restrict to has five values: None (default), Arrival time, Shift, Resource, and Resource + Arrival time.
The Shift restriction only applies if the booking already sits wholly inside the assigned resource's shift. A booking straddling a shift boundary gets no protection from it.
Booking-level Restrict to constraints override constraints defined elsewhere, including Must choose from on the requirement. Assign a booking manually to resource B, set Restrict to = Resource, and the agent keeps it on B even though the requirement says resource A.
Applies to both interactive and batch optimizations — it isn't a batch-only or board-only setting.
Both fields are only usable when the Scheduling Operations Agent is enabled in the environment.
Set from two places: the bookable resource booking form, in the scheduling area; or a right-click on the booking on the schedule board.

When to use / skip

Use it for the exceptions: the booking the customer has already been told about, the one the engineer has committed to, the one with a part in transit to a specific van. Status-level optimization methods are the right tool for policy; these fields are for the handful of bookings a day where policy gives the wrong answer. Skip them as a routine dispatcher habit — every frozen booking is a constraint the optimiser has to work around, and a board full of Do not move bookings will quietly turn optimisation into rearranging the few jobs nobody pinned.

Configuration decisions

Which booking statuses get which status-level optimization method first. Get that right and the per-booking overrides stay rare, which is the point.
Whether dispatchers are allowed to set these at all, and if so who. Both fields sit on the booking form and the board context menu, so restricting use is a training and security-role question rather than a switch.
Whether Schedule if feasible or Do not move is your house default for customer-committed work. The first keeps the agent's flexibility on resource and time; the second removes it entirely.
Whether Restrict to = Shift is worth using given the wholly-inside-a-shift precondition, or whether Resource is the more predictable choice.

Gotchas

Ignore does not mean "protect". The agent won't delete or change the booking, but it will happily schedule other work over the same slot — you get a double-booked resource and no warning. If you meant protect, you wanted Do not move or Schedule if feasible.
Do not move keeps a booking in place even where the placement violates constraints, so it can hold a genuinely invalid schedule together and hide the problem from the optimiser.
The override beats requirement-level Must choose from. That's documented behaviour, but it reads as a bug to anyone who set up the requirement constraint and expects it to win.
The Shift restriction silently does nothing when the booking isn't fully inside a shift. No error, just no restriction.
These are per-booking fields, so they persist on the record. A booking marked Do not move during one crisis stays marked long after the crisis, unless someone clears it.

Consultant notes

Scope the dispatcher training around this before go-live, not after. The four behaviour values sound similar and the difference between Ignore and Do not move is exactly backwards from what most dispatchers guess — that misunderstanding produces double-bookings that get blamed on the agent.
Agree a hygiene routine for clearing overrides. In UAT nobody notices; three months in, a sizeable minority of bookings carry a stale restriction and optimisation results quietly degrade. A view filtered on non-default values, reviewed weekly, is enough.
It's preview, and it's a preview inside a preview — the Scheduling Operations Agent itself isn't GA. Don't let a client design their dispatch process around these fields yet; show them as a safety valve, and keep the RSO or manual path documented as the fallback. See [[feature-copilot-scheduling-operations-agent]] and [[feature-choose-rso-or-manual-dispatch]].
If the client is migrating from Resource Scheduling Optimization, expect to map their existing locked-booking conventions onto these two fields. RSO handled this differently, and the mapping isn't one-to-one — budget a session for it rather than assuming the behaviour carries over.

Public preview under active development — recheck the behaviour values and the Shift precondition after the next release wave, and confirm GA status before anyone designs a dispatch process on it.