What it does

The schedule assistant takes a requirement, works out which resources actually match it — skills, roles, territory, resource type, work location, availability — and shows the dispatcher a ranked set of bookable slots with estimated travel. The dispatcher still picks. It is semi-automated scheduling, sitting between drag-and-drop and RSO.

Key facts

• Launched from Book on a schedulable record, or Find availability on a requirement in the schedule board's lower pane. Both open the same filter pane.
• The default search window is the requirement's From Date to To Date. If those are blank or wrong, results look empty for reasons that have nothing to do with resource availability.
• Resource availability results are capped. The default is 100 entries and the maximum is 1,000, set by Resource Availability Retrieval Limit in Booking Setup Metadata. Raising it costs search performance.
• Search scope is a per-board setting: All resources or Resources visible on board. Unavailable resources can be hidden, or dimmed — dimming only works in Gantt view and only when searching resources visible on the board.
• Five advanced filters ship out of the box: Real Time Mode, Ignore Travel Time, Ignore Duration, Ignore Proposed Bookings, and Allow Overlapping.
• Real Time Mode uses the technician's last synced mobile device location rather than their home or start location. Staleness is governed by the Geo Location Expires After X Minutes scheduling parameter.
• Ignore Travel Time still calculates and stores travel on the resulting booking — it just stops travel blocking availability. Ignore Duration only checks that some slot exists.
• Allow Overlapping surfaces bookings whose Allow Overlap field is set to Yes on the bookable resource booking, so a resource can be double-booked deliberately.
• Time zone comes from the requirement when launched from a record, and from board settings when launched from the board.
• If a user books outside the slots the assistant returned, none of the constraints — capacity, work hours, promised time windows — are validated or enforced.
• Customising the requirement's From/To Date fields with plugins is not supported and produces errors.

When to use / skip

This is the default scheduling motion for most Field Service implementations, and it's what you should train dispatchers on first. It earns its keep as soon as work has real constraints — certifications, territories, promised arrival windows, travel that matters. Skip it for genuinely trivial dispatch (one van, one town, one skill) where drag-and-drop is faster, and skip it for emergency work where the dispatcher already knows who's going. It is not a substitute for RSO: the assistant answers "who can do this one job", RSO answers "what should the whole day look like". Clients who ask for automation and are quoted RSO often discover the assistant plus decent filters is what they actually wanted.

Configuration decisions

• Search scope per board — all resources versus board-visible resources. Large multi-region tenants generally want board-visible; smaller flatter organisations want all.
• Whether unavailable resources are hidden or dimmed. Dimming helps dispatchers understand why nobody matched; hiding gives a cleaner list.
• Whether bookings are visualised from start of travel or estimated arrival, and which one your operations team means when they say "the appointment is at 9".
• The retrieval limit: leave at 100 and narrow the search, or raise it and accept slower results.
• Which of the five advanced filters dispatchers are allowed to use routinely, and which are exception-only. Ignore Duration and Allow Overlapping are the two that quietly destroy capacity planning.
• The Schedule assistant requirement view per entity type, controlling what the dispatcher sees about the job while choosing a slot.

Gotchas

• No results is almost never a bug. In order of likelihood: date window, territory mismatch, characteristics with a proficiency rating the resource doesn't hold, resource not marked schedulable, work hours not defined, or missing geocode.
• Characteristics match on rating value, not just presence. A resource with the skill at a lower proficiency than the requirement asks for is a non-match, and nothing on screen says so plainly.
• Location-agnostic requirements get no travel calculation at all, so remote-work bookings will look artificially efficient next to onsite ones.
• On a large resource pool the retrieval limit means the resource you expected may simply not be in the returned set, and nothing tells you results were capped. Narrow the filter rather than raising the cap.
• Real Time Mode depends on mobile location sync, which depends on the technician having the app open and location permissions granted. Where it isn't, the assistant falls back to configured locations without warning.
• Booking outside the recommended slots is allowed and enforces nothing. Dispatchers under pressure will do this, and your capacity reports will drift from reality.

Consultant notes

• Demo two searches side by side: one that returns good matches and one that deliberately returns nothing, then show how to unpick it. Dispatchers who can diagnose "no results" themselves generate a fraction of the support tickets.
• Agree a house rule on the override filters before go-live and write it down. "Ignore Duration is for emergencies, and the dispatch lead approves it" is a policy the client can actually hold people to.
• Check geocoding coverage on accounts and resources during UAT, not after. Travel-aware suggestions are the assistant's main selling point and they collapse quietly without coordinates.
• If the client wants filters the product doesn't have, look at the filter layout and per-entity requirement views before proposing custom development.
• Watch the gap between promised windows and the assistant's suggestions. If dispatchers routinely book outside the recommendations, the constraint model is wrong, not the tool.

---

Worth revisiting if the advanced filter set grows in a release wave, or the client starts talking about full automation.