… 1 unchanged line …
  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.
    … 19 unchanged lines …
  - 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.
    … 11 unchanged lines …
  
  ---
  
- *Worth revisiting when the customer adds a custom table to the technician workflow, or after any Field Service update that republishes shipped filters.*
+ *Worth revisiting after any Field Service update that republishes shipped filters — check the unpublished sync-filter updates queue*
  

    … 26 unchanged lines …
  - 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.
+ - 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.