Push notifications to the mobile app

What it does

Push notifications send a message to the Field Service mobile app on a technician's phone or tablet, optionally deep-linking straight to a record. They're built with Power Automate using the Power Apps Notification V2 connector — there's no notification engine inside Field Service itself.

Key facts

Delivery is a cloud flow calling the Send Push Notification V2 action, targeting mobile app Field Service and the Field Service Mobile app module.
Recipients are addressed by primary email, not by user GUID or bookable resource. If the resource isn't a user with an email, there's nobody to notify.
Field Service ships a template flow, Field Service – Notify user about booking (UCI app), inside the msdyn_FieldService_patch_update solution. You use Save As to copy it into an unmanaged solution and activate the copy — you don't turn on the managed original.
Two connection references are needed in the default solution: one on Power Apps Notification V2 (the docs name it Field Service Push Notification Connection) and one on Microsoft Dataverse.
Deep linking is done by supplying the table, form and record ID on the action. The shipped example opens the Bookable Resource Booking on Form – Booking and Work Order.
The user needs a Power Automate licence and permission, and notifications must be allowed for the app in the device's OS settings.
Microsoft's test expectation is a notification within about 60 seconds of scheduling a work order to a frontline worker.
Offline devices receive the notification once connectivity returns. Opening it triggers a sync if the record isn't already on the device.
A push notification makes the app sync over cellular even when the user has set sync to Wi-Fi only.
There's a separate privacy notice for Field Service push notifications that the customer needs to accept.

When to use / skip

Worth doing on almost any deployment where technicians receive same-day work. A dispatcher assigning an emergency job at 14:00 has no other reliable way to get a technician's attention, and "they'll see it at the next sync" is a fifteen-minute gap nobody agreed to.

Skip it, or keep it minimal, when the schedule is published the night before and doesn't change — the notifications become noise, technicians turn them off at the OS level, and then the one urgent notification that mattered gets missed too. Also skip if the client's phones are shared devices with a generic account, because notifications are addressed per user email and you can't route them meaningfully.

Configuration decisions

Which events actually warrant a notification: new booking, reschedule, cancellation, high-priority work orders only, or a reminder to complete data.
Whether you start from the shipped booking flow or write your own from the Dataverse trigger. The shipped one is a fine skeleton; most clients outgrow its message text immediately.
Which connection identity the flow runs as, and whether that's a service account with an owned licence rather than a consultant's account.
Whether notifications deep-link to the booking or just open the app. Deep links are better, and they force a sync, which can be a benefit or a battery cost.
Filtering logic — the shipped pattern checks that the bookable resource is of type User before sending, and you need equivalent guards for contractors, equipment and crews.
Message content, and whether any of it counts as personal or customer data appearing on a lock screen.

Gotchas

Flows owned by the implementation consultant break the day their account is deprovisioned. This is the number one cause of "notifications stopped working" three months after go-live.
Editing the managed shipped flow directly creates a layer that the next Field Service update fights with. Save As into your own solution, always.
Bookings created for equipment, crews or contractor resources will send notifications to nobody, or to the wrong person, unless the resource type check is in place.
The Wi-Fi-only sync setting is overridden by a push notification. If the client chose Wi-Fi-only to control data costs, tell them, because notifications quietly reintroduce cellular sync.
Notification volume is a self-inflicted wound. A flow on every booking field change means a technician gets six notifications for one reschedule.
Missing connection references cause the flow to fail silently from the technician's point of view — the flow run history shows the error, but nobody is watching it.

Consultant notes

Move flow ownership to a service account and document it before handover. Include it in the go-live checklist alongside licence assignment.
Demo the deep link, not just the banner. Tapping through to the right booking is what sells this to dispatchers.
Agree a notification policy with the client in writing — which events, what wording. Otherwise the list grows every UAT session and the technicians stop reading them.
Test on a locked device with the app closed. Testing with the app in the foreground proves nothing.
Check the client's mobile device management posture early; some notification content and behaviour is constrained by app protection policies.

Worth another look if the client moves to shared devices or changes who owns the notification flows.