What it does

Field Service turns text addresses into latitude and longitude (geocoding), then uses those coordinates to estimate driving time and distance between a resource's previous location and the next job. Travel is what makes the schedule assistant and RSO produce routes rather than lists.

Key facts

• Maps are turned on in Resource Scheduling > Settings > Administration > Scheduling Parameters by setting Connect to Maps to Yes. Leaving Map API blank means Field Service calls the mapping API on your behalf; supplying your own key means you pay Azure usage costs for it.
• Maps are enabled by default for new environments outside the EU. EU customers must opt in explicitly, with a privacy notice and consent to share data with an external system.
• Geocoding is switched on separately: Settings > Field Service Settings > Other tab > Auto Geo Code Addresses = Yes. Connect to Maps must be done first.
• Only the Street1 field is used for geocoding. Flat numbers and extra address lines in Street1 can make the string too long to resolve.
• When no match is found the system writes coordinates of (0,0), not null. Any custom logic, report or integration that reads coordinates has to filter these out or it will route people to the Gulf of Guinea.
• Individual records can be geocoded manually with Geo Code on the command bar of a service account or functional location, confirming the pin on a map dialog.
• Travel time is calculated only when the requirement is on site, the booking falls inside the resource's working hours, and there's a valid preceding location — the resource's own location for the first booking of the day, or the previous booking's location after that.
• Driving is the only supported mode of travel. There is no walking, transit or cycling model.
• Drag-and-drop on the board does not calculate travel by default. Set Auto Update Booking Travel to Enabled in Scheduling Parameters to have travel added before the booking start when start and end locations are known.
• Fulfilled Duration subtracts estimated travel from the allocated time so reporting shows actual work rather than work plus driving.
• The board map can display current traffic via View Settings > Traffic, but standard travel time calculations ignore real-time and historical traffic. RSO's goal settings can use historical traffic, capped at 500 requirements per scope.
• Real Time Mode in the schedule assistant uses the technician's last synced device location instead of a configured one, governed by the Geo Location Expires After X Minutes parameter.

When to use / skip

If technicians drive to customers, you configure this — it isn't optional and it isn't a phase two item. The only implementations that can genuinely skip it are remote-only or facility-based operations where every requirement is location agnostic. What is a judgement call is how far you go: address suggestions, location tracking and geofencing are separate switches with their own privacy and licensing implications, and plenty of clients want the routing benefit without the tracking conversation. Take the mapping consent question to the client's data protection lead early if they're in the EU, because "the schedule assistant doesn't show travel" traced back to an unsigned consent is an embarrassing way to lose a fortnight.

Configuration decisions

• Default mapping API versus your own key, and who owns the Azure cost if you bring your own.
• For EU clients, whether and when consent to share address data externally is given, and by whom.
• Whether Auto Update Booking Travel is on, which decides whether manual drag-and-drop bookings carry realistic travel or none.
• Where each resource's day starts and ends — personal address, organisational unit, or a depot — since the first booking's travel depends entirely on it.
• Whether Real Time Mode is enabled for dispatchers, and the staleness threshold you're prepared to trust.
• Address data standards: what goes in Street1 versus Street2, and how you'll clean the existing account base before go-live.

Gotchas

• (0,0) coordinates are the classic silent failure. Nothing errors, the record looks geocoded, and the resource appears to be four thousand miles away.
• Turning on auto geocoding does not retrospectively fix records created before it. Migrated accounts need a deliberate bulk geocode.
• Location-agnostic requirements never get travel, so a mix of remote and onsite work makes capacity figures look better than they are.
• Bookings outside working hours get no travel calculation at all, which quietly under-books overtime and emergency work.
• Real Time Mode depends on the mobile app syncing location. Where permissions are declined or the app is closed, it falls back without telling the dispatcher.
• Travel appears before the booking start when auto-update is on, so a "9am booking" may mean the technician leaves at 9. Agree with the client whose definition wins, and set the board's book-based-on setting to match.

Consultant notes

• Run a geocode quality report before UAT: count records with null coordinates and with (0,0), broken down by country. It's a five-minute query that reliably finds a data cleanup task nobody scoped.
• Demo the difference between travel on and travel off using the client's own worst territory. Rural clients discover their duration estimates were fantasy.
• For EU clients, get the maps consent decision in writing and note the date. It affects every downstream scheduling feature.
• Check UK postcode handling specifically — abbreviated or partial postcodes resolve to a district centroid, which looks plausible and is several miles out.
• Before go-live, confirm resource start and end locations for every technician, including contractors and part-timers. Missing start locations are the most common reason the first job of the day gets no travel.

---

Worth another look if the mapping provider or its licensing changes, or when the client asks about traffic-aware scheduling.