Choosing the Field Service mobile app or a custom technician app

What it does

The Field Service mobile app is a model-driven Power App for iOS, Android and Windows that technicians use to work their bookings, update statuses, record time and parts, complete inspections and capture signatures — offline by default. The alternative is building a canvas app, a custom model-driven app, or something outside the platform entirely. This is the decision that generates the most heat on field service projects and gets made for the wrong reasons more often than any other.

Key facts

It's a model-driven app on Power Platform, included in the Field Service licence at no extra charge. A custom app for the same users doesn't escape that licensing — you just maintain two apps.
Offline-by-default: technicians work against a local database and sync, manually or automatically. This is not "offline as a fallback" — it's the normal operating mode.
Offline behaviour is governed by the Field Service Mobile - Offline Profile. Start from the shipped profile and don't remove the default record types.
The offline profile allows a maximum of 15 linked tables, counting downstream tables. That's the hard architectural ceiling on what a technician can see offline.
Several tables can't be used offline at all: Purchase Order, Agreements, RTV and RMA. Nor can SharePoint documents, knowledge articles, inventory validation, export to PDF or field mapping. Web resources are only partially supported.
Power Automate flows only run when there's connectivity or at next sync. For on-demand offline logic you need offline-capable JavaScript instead.
Queries for records outside the offline profile return empty results, not an error. Silent, and a pig to diagnose in the field.
Guidance for custom controls: cap concurrent offline database calls at 2–4, page results (?$top=50&$skiptoken=), restrict columns with ?$select=, and filter at query level rather than in the control.
Customisation covers navigation, views, booking and work order forms, added controls, and a custom app module. A refreshed mobile experience shipped in 2024 and is enabled by administrators in the mobile app setup.

When to use / skip

Use the shipped app. Almost everything a technician does — bookings list, calendar, work order detail, statuses, service tasks, products and services, inspections, photos, signature, service report — is there, offline, and maintained by someone other than you.

The reasons people give for going custom are usually solvable inside the app. "The UI is too complex" is a form and view exercise, plus the 2024 experience. "We need a guided flow" is service tasks and inspections with branching. "We need a specific control" is a PCF component. "It doesn't look like our brand" is not a reason to take on an offline sync engine.

There are cases where custom is right. If technicians aren't Dynamics users at all — subcontractors, third-party engineers, one-off site staff — a purpose-built app or portal against a narrower data set is cleaner and cheaper to licence. If the device isn't a phone or tablet — a ruggedised handheld, a vehicle-mounted terminal, a wearable — the model-driven app may not run acceptably. And if the job flow is nothing like a work order visit and the offline data set won't fit 15 linked tables, you're fighting the platform.

The middle path most projects should take: the shipped app for employed technicians, plus a custom page or embedded canvas app for the one or two screens that genuinely need a bespoke layout. You keep the sync engine and the licence, and buy only the UI you need.

Configuration decisions

Decide the offline data set first, in tables, and check it against the 15-linked-table ceiling before designing anything else. This constraint should drive the design, not be discovered by it.
Decide the offline filter scope — bookings for the next N days, records in the technician's territory, assets at the sites they cover. Wide filters and "All records" are what make sync slow.
Decide whether you're on the new mobile experience or the classic one at go-live, and stick with it through UAT. Switching mid-project revalidates every form change.
Decide which capture is a service task, which is an inspection, and which is a form field. This shapes the technician's day more than any styling choice.
Decide the sync policy: automatic cadence, manual force-sync, and what the technician is told to do when they lose signal mid-job.
Decide the device posture — Intune-managed corporate devices or BYOD — since it affects push notifications, location tracking and what you can enforce.

Gotchas

The 15 linked table limit includes downstream tables pulled in by relationships. Teams count their own tables, hit the ceiling unexpectedly, and have to redesign the offline profile late.
Agreements, purchase orders, RMA and RTV are unavailable offline, and knowledge articles don't display. Any process expecting a technician to raise a purchase order or look up a fix at the van needs rethinking.
"Related rows only" offline filters inherit the parent table's filter. You can restrict data far more than you intended and see empty grids with no explanation.
Empty results instead of errors is the defining support problem. Check the offline profile first whenever a technician says "the record isn't there".
Power Automate flows that people assume run on save do not run offline. Business logic technicians depend on must be offline JavaScript or must be honestly documented as deferred.
Custom controls that behave on a desk with a fast connection fall over against production data volumes on a phone in a basement. Test with realistic volumes, on a real device, offline.

Consultant notes

Demo the shipped app on a real phone in aeroplane mode in the first workshop. It kills the "we need to build our own" conversation more effectively than any slide.
When a client insists on custom, ask them to specify what the technician does that the app can't. Write the answers down; usually two of five are real and both are form changes.
Tell the client that offline is a design constraint, not a feature toggle. The 15-table limit and the unsupported tables belong in the solution design document.
Push back on wide offline filters. Sync time is the number technicians will judge the project on, and it's set by decisions made in week two.
Before go-live, run a field trial with the real devices, real signal conditions and a full day's bookings. Office testing over Wi-Fi proves nothing here.

Worth another look after the next wave of the new mobile experience, or if Microsoft raises the offline linked-table limit.