Offline for model-driven apps

What it does

A local copy of a defined slice of Dataverse, kept on the device and synced in the background. You turn on Can be used offline in the modern app designer, attach an offline profile that lists tables and row filters, and the player then reads and writes locally whether or not there's a connection.

Key facts

Offline-first is the default mode. There's no user toggle between online and offline — the app always works against the local database and syncs in the background, which is what makes the behaviour consistent.
Total records synced is capped at 3,000,000 including the hidden tables the platform uses for offline itself. Microsoft's own guidance says to stay under 200,000 for decent performance.
A table must be marked Can be taken offline in its settings before it can go in a profile. Some standard tables have it by default; some can't be enabled at all.
One app maps to one profile, but a profile can be shared across several apps. Apps sharing a profile share the local store, so the data downloads once.
Profile filters cap out at 15 relationships per table, and the count is transitive — referencing a table that itself has N relationships adds N+1. Only one M:M or 1:M is allowed within those 15. No circular or self-references.
An offline profile can hold at most 14 image columns across all tables.
Field-level security and field sharing aren't supported offline. Personal views aren't supported; only system and quick views are.
Calculated and rollup columns aren't recalculated on the device. They're re-evaluated server-side when the row syncs back.
Business rules work offline. Business process flows work offline only if they're single-table and every BPF on that table is in the profile.

When to use / skip

Turn this on for any app a field user will run on a phone, even one you think will always have signal. Offline-first isn't only about disconnected working — it's the thing that makes the app feel fast, because every read hits local storage rather than the network. Skip it for apps used by office staff on a tablet in a building with wifi, where the profile design and testing effort buys you nothing. And skip it, or rethink the app, if your scenario genuinely needs the whole dataset: the moment you're arguing about how to get 400,000 rows onto a phone you've designed the wrong app.

Configuration decisions

Whether to build a separate, lighter app for mobile users rather than making the desktop app offline-capable, which is Microsoft's own recommendation and usually the right call.
Which filter to use per table — organisation rows, all rows, related rows only, or custom — and that maps to whether the table is standalone, related or reference data.
Whether the profile is Default (everyone with app access) or Restricted to selected users, remembering that restricted profiles need an admin to assign users.
Per-table sync intervals, so slow-moving reference data isn't re-checked as often as work orders.
Whether users get Allow users to work in online mode, which lets them reach data outside the profile when connected, and whether that undermines the point of the filters.
Whether to use column selection to strip unused columns from the download, which is the single biggest lever on first-sync time.

Gotchas

Adding a custom filter to a table that's already set to Related rows only is treated as an OR, not an AND. Users download far more than you intended. To get AND behaviour, clear the related-rows option and put the relationship into the custom filter.
Column filtering in grids is disabled once an offline profile exists, even when the device has a connection. Users notice this immediately and report it as a bug.
Global search falls back to categorised search offline and only searches one table at a time. Dataverse search doesn't work offline at all, regardless of connectivity.
HTML web resources are unsupported offline on iOS and only partly supported elsewhere. If the form depends on one, it will work on Android and fail on iPhone. Use a PCF control or form handler events instead.
Removing tables from the shipped Field Service or Sales offline profiles breaks forms and views at runtime. Adjust the filters, not the table list.
Custom command-bar buttons without the Mscrm.IsEntityAvailableForUserInMocaOffline rule don't render in offline-first apps.

Consultant notes

Test the profile with a real user's data volume, not yours. A regional manager sees an order of magnitude more rows than the field engineer you demoed to, and the profile that syncs in two minutes for one takes forty for the other.
Price the offline profile as a design activity in its own right. It's data modelling work, not a checkbox, and it comes back every time someone adds a table to the app.
Warn the client that first sync is the moment of maximum risk on go-live day — fifty engineers doing an initial sync over 4G in a depot car park is a different experience from one tester on office wifi.
If the client is running Field Service or Sales, start from Microsoft's default profile and tune the filters. Building one from scratch means discovering the missing tables one runtime error at a time.

Worth revisiting if the 3,000,000-record ceiling or the 15-relationship profile limit moves, or after the next release wave changes offline behaviour.