What it does

Location tracking has the Field Service mobile app report a technician's position on an interval, storing it in Dataverse so dispatchers can see where people are and the schedule assistant can route from a live position. Geofencing sits on top: a circle is drawn around a booking's service location, and enter and exit events fire as the tracked resource crosses it.

Key facts

• Tracking is switched on at Settings > Geolocation > Geolocation Settings, with Enable Location Tracking set to Yes, a refresh interval (60–300 seconds is the documented recommendation) and a per-day tracking time window.
• Positions land in the Geolocation Tracking table (msdyn_geolocationtracking), and only during the configured tracking times. Users need read access to msdyn_geolocationsetting; the Field Service - Resource role has it by default.
• The technician must grant precise location and, on most devices, Always allow for tracking to continue with the app in the background.
• Actual sampling is best-effort. Device OS, battery saver and other apps all reduce the real frequency below whatever you configure.
• How long a position is treated as current is set separately: Resources > Scheduling Parameters > Geo Data tab > Geo Location Expires After X Minutes.
• getCurrentPosition in the Xrm.Device API is the alternative — a one-off location capture on a button press, with no background tracking at all.
• Geofencing needs maps connected and auto geocoding enabled first, so accounts and work orders carry latitude and longitude.
• Geofences are configured through Entity Configurations: Account enabled as Geofence with a default radius, Bookable Resource enabled as Geo tracked with latitude, longitude and a timestamp column.
• Geofences are circles only — no polygons — and there is a documented minimum radius (25.59 feet, roughly 8 metres).
• Creation and cleanup run either as the classic workflows (GenerateGeofenceWhenBookingIsCreated, DeleteGeofenceWhenBookingIsCompletedOrCanceled, Update Geofence instance coordinates) or as the flow equivalents in the Geofencing for Field Service solution under the Use Enhanced Background Processing option, which the docs mark as preview.
• Geofence trigger filters limit which bookings generate geofences, filtered on a date column such as Start Time over a window like yesterday to tomorrow. Without them, volume becomes a performance problem.

When to use / skip

Location tracking is worth it when dispatchers actually re-dispatch during the day. If the schedule is fixed at 07:00 and never changes, live positions are surveillance with no operational payoff, and you'll spend the project defending it.

Geofencing is narrower still. It's genuinely useful for automatic arrival and departure timestamps, for "technician is 10 minutes away" customer messages, and for compliance evidence on sites where attendance has to be proven. It is not a substitute for the technician pressing Travel and Start. Most projects don't need it, and those that do usually need it for one specific customer contract rather than the whole business. Be honest with the client that the technician's phone is the sensor: dead battery, no signal or a revoked permission all mean no events.

Configuration decisions

• Refresh interval and tracking hours — the trade-off between dispatcher visibility and battery life, and the point at which tracking outside shift hours becomes an HR problem.
• Interval tracking versus on-demand getCurrentPosition capture at specific moments in the workflow.
• Geofence radius per account type. Small radii miss events on large sites; large radii fire early in dense urban areas.
• Workflows or the preview flow-based background processing for geofence lifecycle.
• The trigger filter window, which is the main lever on how many geofence records exist at once.
• What actually happens on an enter or exit event: push notification, auto-populating arrival time, a customer message, or just an audit record.

Gotchas

• Location permission is the technician's to give and to take away. Someone switching the app from Always to While Using silently ends background tracking, and nothing in the admin UI tells you.
• Tracking only writes to the server inside the configured tracking times. Configure 08:00–17:00 and then wonder why the 18:30 emergency job has no positions.
• Without trigger filters, every future booking gets a geofence. On a customer with months of forward scheduling that's a large table and a slow one.
• Testing geofencing means physically travelling to a location or expanding the radius to wherever you're sitting. Plan for that; it's an afternoon, not a unit test.
• Geocoding gaps break geofencing quietly — an account with no latitude and longitude produces no geofence and no error a dispatcher will see.
• Location data is personal data. Works councils, unions and the client's own privacy team may have views, and retrofitting consent after go-live is painful.

Consultant notes

• Raise the privacy conversation in the first workshop, not at UAT. Get the client's HR or works council position in writing before you build anything on it.
• Demo the schedule board with live positions to dispatchers and the geofence event to operations — they care about different halves of this feature.
• Set expectations on accuracy explicitly. Consumer-grade GPS in a van in a city is not survey-grade, and clients who plan to bill from it need to know that.
• If arrival timestamps are the actual requirement, check whether the technician pressing a button gets you 95% of the value for 5% of the effort. Often it does.
• Before go-live, confirm battery impact with a real technician over a full shift. It's the most common reason tracking gets switched off in month two.

---

Worth another look when the enhanced background processing option leaves preview, or if the client's privacy position changes.