Location, maps and geocoding configuration

What it does

Field Service turns addresses into coordinates and coordinates into travel time, and it needs a connection to a mapping service to do either. The configuration is split across two places: Connect to Maps in the Resource Scheduling parameters, and Auto Geo Code Addresses in Field Service Settings. Without both, the schedule board still works but travel time, distance and proximity search quietly stop being meaningful.

Key facts

Connect to Maps lives in the Resource Scheduling app under Settings > Administration > Scheduling Parameters, on the Resource Scheduling record. Set it to Yes to get maps, travel times and location data.
Maps are enabled by default for new environments outside the EU. EU customers have to opt in explicitly, having accepted the privacy notice and the sharing of data with an external system.
Leaving the Map API field blank means Field Service calls the mapping API on your behalf, at no separate charge. Supplying your own key routes calls through your own subscription and you pick up the Azure usage cost.
Connecting to a mapping service shares data — addresses and coordinates among other things — with a system outside your Dynamics 365 environment, Government Cloud included. Use of the service is under that provider's terms.
Auto Geo Code Addresses is a separate switch, on the Other tab of Field Service Settings, and geocoding depends on the maps connection being in place first.
Geocoding uses Street 1 only. Street 2 and Street 3 are ignored, and cramming flat or unit numbers into Street 1 risks a string too long to process.
When no match is found, the system returns coordinates of (0,0) rather than failing. Any custom logic reading latitude and longitude has to filter that out or you get routes to the Gulf of Guinea.
Records can be geocoded on demand with the Geo Code command on a service account or functional location.
Enable Address Suggestions gives typeahead address entry, but only on account, work order and booking forms. It's not available for other forms or for customisation, and it's hidden in the form editor.
The Field Service - Resource role has read-only privileges on addresses by default, so technicians can't correct a bad address themselves.
Live resource positions on the schedule board come from a different set of parameters again — the Geo data tab of Scheduling Parameters, with Geo Location Refresh Interval Seconds and Geo Location Expires After X Minutes controlling how fresh a position has to be before the board falls back to the previous work order or start location. Enable Custom Geolocation with the custom entity, resource, latitude, longitude and timestamp field names lets you feed positions from telematics rather than the mobile app.

When to use / skip

Turn maps and geocoding on for essentially every project. Travel time is one of the main reasons a client buys Field Service rather than scheduling in a spreadsheet, and the schedule assistant's radius search, the resource map view and Resource Scheduling Optimization all depend on coordinates being present and correct.

Skip it only in genuinely location-agnostic work — remote support, depot repair, or an inspection business where every job happens at the same handful of sites. Even then, geocoding those few sites costs nothing and keeps options open.

Where you should think carefully rather than skip is the API key question. The default arrangement, with Field Service calling the mapping service on your behalf, is right for the vast majority of clients. Bringing your own key is for organisations that already run their own mapping estate, need particular provider behaviour, or have contractual reasons to control the calls. It adds cost and an ownership question for no functional gain otherwise.

Configuration decisions

Whether to use the default mapping connection or supply your own Map API key, and if the latter, who owns the Azure subscription and its bill.
For EU customers, whether the organisation accepts the data sharing that maps require, and who signs that off — this is a privacy conversation, not an admin toggle.
Whether address data is clean enough to geocode in bulk, and what the plan is for the addresses that come back as (0,0).
How address components map into Street 1, Street 2 and Street 3 during data migration, given that only Street 1 is geocoded.
Whether resource positions come from the mobile app or from a custom telematics source, and if custom, which entity and fields carry them.
How long a stale position stays valid on the schedule board before it falls back — the geolocation expiry and refresh interval values.

Gotchas

Geocoding without a maps connection does nothing. The setting saves happily and no error appears; addresses simply never get coordinates.
Migrated data does not geocode retrospectively just because you turned the setting on. New and updated records are handled; a back catalogue of accounts needs a deliberate bulk pass.
(0,0) results look like valid coordinates to every downstream consumer — reports, custom plugins, routing logic, optimisation. Filter them explicitly.
Putting "Flat 4" or a building name into Street 1 alongside the street is a reliable way to get poor or missing matches, and it's exactly what most legacy address data looks like.
Address suggestions can't be added to a custom form. If the client has replaced the work order form wholesale with something bespoke, check the suggestion behaviour survived.
Government Cloud environments are not exempt from the external data sharing maps involve — raise it early with public sector clients.

Consultant notes

Do a geocoding dry run on a sample of real client addresses during discovery. The match rate tells you more about the data migration effort than any workshop will.
Demo travel time on the schedule board with and without geocoding. Bookings with no travel estimate make the case for cleaning address data.
Tell the client plainly that maps means sending addresses to an external service, before procurement or the DPO finds out from someone else.
Before go-live, check a handful of geocoded service accounts on the map by eye. Coordinates that are technically valid but a village away are the failure mode nobody catches automatically.
If technicians are complaining about wrong addresses, remember they can't fix them — either build a correction process, or budget the role change.

Worth revisiting if the client changes mapping provider, or if address data quality turns out worse than the discovery sample suggested.