Customising the Field Service mobile app

What it does

Field Service Mobile is a model-driven app, so you customise it the same way you customise anything else on Power Platform: navigation, views, forms, controls and business logic. The difference is that every change has to survive on a phone, offline, in the hands of someone wearing gloves.

Key facts

The app module is Field Service Mobile. Technicians need the Field Service - Resource security role plus the matching field security profile; the app itself is shared to that role in Power Apps.
The primary form is the booking and work order form. Most delivery work is form design on that form and the related work order product, work order service and inspection surfaces.
There's a separate new mobile experience, switched on at Settings > Mobile settings > Features in the app. Microsoft's setup article lists a minimum app version of 2408.2 and solution version 8.8.122.6, and a Field Service – New Mobile Experience security role for access.
The new experience does not support offline mode, and on Windows it falls back to the Unified Interface regardless. That single fact decides the choice for most field-based deployments.
Users don't reinstall anything when you switch experiences — existing installs pick it up.
Controls are added per column with Show component on set for Mobile and Tablet. Use PCF components; web resources are only partially supported offline.
Custom business logic should use OnChange rather than synchronous OnSave handlers. Synchronous OnSave logic is the classic cause of a booking that won't complete on a device.
If you clone or build a custom app module, you must carry over the default business logic that drives travel and time calculations, otherwise timestamps stop populating.
Required columns matter more than usual: leaving the Work Order column off a customised Work Order Product form breaks the record silently.
The modern form designer is the recommended one for forms with several auto-expanding multiline text fields.
Enable Address Suggestions is a Field Service Settings option under Other; the Get Directions button is not configurable and always opens the device's default map app.
Some ribbon and command bar buttons are hidden automatically when the device is offline.

When to use / skip

You will customise the booking form — that's not really in question, because every client has fields technicians must capture. What you should push back on is wholesale redesign. The shipped form has been tuned for one-handed use and offline behaviour, and teams who rebuild it from a desktop mock-up produce something that scrolls forever and syncs badly.

Custom app modules are a heavier commitment. They make sense when you have genuinely distinct technician populations with different data needs, and they're a mistake when the real requirement is "hide four fields from the plumbers". Use form scripting, business rules or a second form before you clone the app.

Configuration decisions

New mobile experience or Unified Interface. Offline support is the deciding factor, and it isn't reversible per user without changing role assignments.
Which form the technician lands on for a booking, and what's on the first screen without scrolling.
Whether custom capture is a form field, a PCF control or an inspection — inspections carry their own versioning and reporting behaviour.
Where custom logic lives: client-side JavaScript that runs offline, versus Power Automate that only fires when the device is connected or at next sync.
One app module for everyone, or per-persona modules — and if the latter, who owns keeping the default business logic in each.
Which views appear in mobile navigation, remembering each one has to be offline-capable.

Gotchas

Adding a column to a form does nothing on the device until that column is in the offline profile and the profile is republished. This catches people every single project.
Synchronous OnSave scripting behaves quite differently offline from the web client — logic that "works in the browser" can leave a technician unable to save.
Power Automate flows attached to mobile actions look instant in a demo on Wi-Fi and do nothing in a basement. Test with the radio off.
Cloned app modules quietly lose travel and time calculation behaviour if the default logic isn't brought across, and nobody notices until someone runs a timesheet report.
Views that reference related tables not in the offline profile throw a "view has related entities not available offline" error rather than degrading gracefully.
Switching a user to the new mobile experience takes their offline capability away. If they work in poor coverage, that's a functional regression, not a UX upgrade.

Consultant notes

Do form design on an actual phone, in the field if you can. A form that looks tidy on a 27-inch monitor is four screens of scrolling on a handset.
Demo the offline case, not just the happy path. Clients sign off far more confidently when they've seen the app work in flight mode.
Agree a rule with the client's team: every form change goes through the offline profile check before it's promoted. Make it part of the deployment checklist.
Push back on "just add a flow for that" when the requirement is on-device. It's the most common request and the most common cause of an unreliable field app.
Before go-live, verify the app on every device type in scope — iOS, Android and Windows behave differently enough that one untested platform will produce surprises.

Worth revisiting once the new mobile experience gains offline support, since that changes the main design decision here.