Almanac
Microsoft/d365fsDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Field Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across work orders, scheduling and dispatch, resource management, mobile app, asset management, inspections, IoT, Copilot, and administration.

d365fs/02-scheduling-and-dispatch/feature-time-zone-agnostic-scheduling.md
feature-time-zone-agnostic-scheduling.mdv1 · history
CurrentApplies to Resource Scheduling / Field ServiceUpdated 3 weeks agoSource Microsoft Learn ↗

What it does

Normalises resource working hours to UTC inside the schedule assistant, so a requirement can be matched against resources in different time zones without anyone doing the conversion in their head. Two resources who both work 9 to 5 locally show as 9 to 5 UTC, whether one sits in Eastern Time and the other in Pacific.

Key facts

  • Switch it on in the booking settings for the entity: an admin sets Ignore Time Zone in Schedule Assistant to Yes.
  • It only applies to requirements with a Work Location of Location Agnostic. Onsite and facility work are out.
  • It doesn't support crews, pools, requirement groups or promised time windows.
  • It works only in the schedule assistant. Quick scheduling, the Specify Pattern control and the msdyn_SearchResourceAvailability API don't honour it.
  • While the assistant is open, the Gantt is fixed to UTC and you can't change the board time zone.
  • On exit the board returns to its own time zone. Each booking keeps the resource's local start and end times, worked out from the resource's calendar on the booking date.
  • Appointments aren't adjusted to each resource's local time, so availability can look wrong where appointments are in play.

When to use / skip

Use it for remote and location-agnostic work spread across regions: remote support, virtual inspections, back-office tasks assigned from a global pool of people. Anything where "9 to 5 in their day" is the real constraint.

Skip it for onsite work, crews and anything with promised windows. The limitations list is long enough that the feature is narrow by design, and forcing it wider produces availability that looks right and isn't.

Configuration decisions

  • Which entities get the setting. It's per bookable entity through the booking settings, not a global switch. Decide it for work orders, and for any other enabled entity, separately.
  • Work Location values. Because only Location Agnostic requirements qualify, check your work order types and templates actually default to it where you want this behaviour.
  • Board time zone for the rest of the day. Each schedule board tab has its own time zone. Pick one that dispatchers can read at a glance, then leave it alone.
  • Resource calendar time zones. Booking times come from the resource's calendar time zone on the booking date. Clean those up before go-live.

Gotchas

  • Dispatchers who use quick scheduling or the pattern control will see no agnostic behaviour at all, and will report it as a bug. It's two scheduling paths, and only one is covered.
  • Daylight saving time moves the gap between resource and board. A resource on 9 to 5 local keeps those hours across the change, but their bookings can shift by an hour on the board when the two zones change on different dates or only one observes it.
  • Date and time format comes from the user's personal settings, not the board. Two dispatchers can read the same booking differently without anything being wrong.
  • If a booking appears at an unexpected time, compare the board time zone with the time zone on the resource's calendar before suspecting the scheduling engine.
  • The schedule assistant's own time zone depends on how you opened it: the requirement's zone from Book, the board's zone from Find Availability, and UTC when this feature is on. People forget which route they took.

Consultant notes

  • The scoping mistake is promising "follow-the-sun scheduling" for a mixed onsite and remote operation. This feature touches only location-agnostic requirements and only the assistant; say that in the first workshop, with the limitations on screen.
  • Test across a daylight saving boundary in UAT. Plenty of designs look right in October and wrong the weekend the clocks change in one country but not the other.
  • If the client needs crews or promised windows across regions, the answer is a different design, not a workaround. Better to have that conversation at scoping than after the board is built.
  • Get dispatchers to rehearse the Book versus Find Availability difference. It's the single biggest source of "the times are wrong" tickets.

Microsoft updated this page in October 2026 — worth revisiting after the next Field Service release for any widening of the supported scenarios.

Was this accurate?
Related
Schedule assistant and its filters02-scheduling-and-dispatchBookable resources and resource types03-resource-managementResource work hours, calendars and work hour templates03-resource-managementRequirement groups and multi-day scheduling02-scheduling-and-dispatchBooking-level restrictions in the Scheduling Operations Agent02-scheduling-and-dispatchChoosing Resource Scheduling Optimization or manual dispatch11-decision-guides