What it does

The mobile offline profile is the definition of which Dataverse rows land on a technician's device. It's a set of tables, each with a filter, a set of related tables, and a sync frequency, published from the Field Service Mobile app's settings in Power Apps. Everything the app can show, search or validate offline comes from that profile.

Key facts

• The default profile ships a five-minute sync interval for bookings, work orders, incidents, products, services, service tasks and not-to-exceed records, and the booking filter downloads active bookings assigned to the current user that start or end today or in the next seven days. Both are adjustable, and both change between Field Service updates — read the profile in the environment rather than trusting a number from the last project.
• If a technician reports missing data, check they appear under Users with this profile before touching filters. Profile assignment, not filter scope, is the usual cause.
• Field Service ships a profile called Field Service Mobile - Offline Profile, already populated with the tables the standard app needs. It is the intended starting point, not an example.
• You turn it on from Power Apps > Apps > Field Service Mobile > Settings > General > Can be used offline, then pick Default (recommended) — every user with app access gets offline mode — or Restricted to selected users.
• The default booking filter is time-boxed rather than "all records" (bookings starting in the next seven days out of the box). Wide date ranges and "All records" filters are the usual cause of a first sync that never finishes.
• A table can pull in related tables, but there's a ceiling of 15 linked tables including downstream ones. Chained relationships eat that budget quickly.
• The Related rows only filter type makes a table inherit its parent's filter. Handy, but it silently narrows data if the parent filter is tight.
• Lookups referenced by a filter must themselves be in the profile. Miss one and you get errors or a blank screen on the device rather than a warning in the maker portal.
• Filters you have edited are not updated when Field Service updates. Filters you haven't touched do get updated, but land unpublished so an admin reviews them first.
• Several tables are documented as not working offline or actively causing errors: Purchase Order, Agreements, RTV and RMA. Field mapping, SharePoint documents, viewing knowledge articles, export to PDF and inventory validation also need connectivity.
• Profiles move between environments as solution components: in a solution, Objects > Add existing > More > Offline profile, then export and import.
• Records created offline still have to satisfy the profile filter to survive the round trip.

When to use / skip

There is no skip. If technicians use the mobile app, they're on the offline profile whether you designed it or not — the app runs offline-first once the initial download completes. The real question is how much you change. On most deliveries the answer is "copy the default, add your custom tables, tighten one or two filters, leave everything else alone". Teams who rebuild the profile from scratch to feel in control spend the rest of the project chasing missing-data tickets.

The exception worth planning for is a customer with genuinely large reference data — a product catalogue in the tens of thousands, or asset hierarchies per site. That needs a deliberate filter design and a device test with production-sized volumes, not a sample dataset.

Configuration decisions

• Default profile for all app users, or restricted profiles per region or business unit. Restricted means someone has to maintain assignments forever, and mis-assignment shows up as "wrong data" tickets.
• The booking window: how many days forward, and whether you also need days back for rework and unposted time entries.
• Which custom tables go on the device, and whether they carry their own filter or inherit through Related rows only.
• Whether files and images sync for each table. Photos are the largest single contributor to device storage.
• Which views and forms the mobile app modules expose — every extra view is more data and more chance of a "view has related entities not available offline" error.
• Whether custom logic on the device runs as offline-capable JavaScript or as a PCF control, and how its queries are paged.

Gotchas

• Microsoft's updates to the shipped profile arrive unpublished. A Field Service update refreshes sync filters you haven't touched, but leaves them unpublished so an admin can review and accept or keep the previous behaviour. Filters you have edited are skipped entirely; relationships take the update while keeping your changes. So after every Field Service update there is a review step nobody has diarised, and skipping it means running on filters Microsoft has already moved on from.
• Publishing profile changes creates an active solution layer. That matters if you move profiles between environments on a controlled path — the layer sits on top of the managed solution and will out-rank a future import. Settle the layering strategy before the first production publish, not after two environments have diverged.
• A custom control or script that queries rows the profile filters out returns an empty result offline — no error, no notification, the field just looks empty and the technician assumes the record is wrong. If the table isn't in the profile at all, it's worse in a different way: the offline API can be unavailable entirely and the operation returns an error. Microsoft tightened this wording in September 2026; the old blanket "returns empty, never errors" reading was wrong.
• Don't hard-code one paging pattern in a custom control. Use the paging mechanism for the query type — FetchXML page and paging-cookie values, for instance — and follow the paging information the API hands back, rather than assuming $top/$skiptoken works everywhere.
• Editing a shipped filter opts that filter out of future Microsoft updates permanently. Note which ones you touched; nobody remembers two releases later.
• Web resources are only partially supported in offline mode. Build with PCF instead, and use Xrm.WebApi.online explicitly where a command genuinely needs the server.
• Power Automate flows do not run on the device. On-demand logic that must work with no signal has to be client-side JavaScript.
• The 15-linked-table limit counts downstream relationships, so a seemingly small addition can push an existing branch over the edge and break publishing.
• Missing a lookup table used in a filter produces a blank screen on the device, which reads to the client as "the app is broken" rather than "a config row is missing".

Consultant notes

• Demo the profile editor to the client's admin, not just the app. They need to understand that adding a field to a form does nothing until the table and column are in the profile and it's republished.
• Test on a real device with a real technician's security role and a production-sized dataset before UAT. A dispatcher account with a system administrator role will never reproduce what the technician sees.
• Get a decision on photos early — resolution, whether they sync, and how long they stay on the device. Storage complaints arrive about six weeks after go-live.
• Put the profile in a solution from day one so it promotes with everything else. Hand-editing it in production is how environments drift apart.
• Before go-live, walk the device status page with the support team so they know where last-sync times and sync errors live.

---

Worth revisiting after any Field Service update that republishes shipped filters — check the unpublished sync-filter updates queue