Designing the mobile offline profile

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

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

Any custom control or script that queries data the profile doesn't hold returns an empty result offline. No error, no notification — the field just looks empty and the technician assumes the record is wrong.
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 when the customer adds a custom table to the technician workflow, or after any Field Service update that republishes shipped filters.