Field Service Mobile App Builder
The Field Service Mobile App Builder is a Setup tool that lets Salesforce admins customize what mobile workers see inside the Field Service mobile app on iOS and Android.
Definition
The Field Service Mobile App Builder is a Setup tool that lets Salesforce admins customize what mobile workers see inside the Field Service mobile app on iOS and Android. You build configurations that control tabs, screens, fields, actions, and Lightning components without writing code. The work happens in a drag-and-drop canvas, and changes reach the app once you publish the configuration.
It is the technician-facing counterpart to dispatcher tools like Field Service Settings. Because the mobile app runs offline-first, the builder also shapes which records prime to the device and which actions queue when there is no signal. You can tailor the layout by user profile, so a plumber and an HVAC technician each get a screen suited to their day.
How the builder shapes the technician's screen
Where it lives and what a configuration is
You open the builder from Setup by searching for Field Service Mobile App Builder. The unit of work is a configuration: a saved set of tabs and screens that the app reads at sync time. You create one, edit it on the canvas, then publish it so mobile workers receive the changes. Nothing reaches the device until you publish, which gives you a safe space to draft and review before rollout. A single org can hold several configurations. That matters because field crews rarely share one workflow. The builder lets you assign different configurations by user profile, so the layout a senior technician sees can differ from a junior one. Salesforce ships a default configuration, and many teams clone it as a starting point rather than building from a blank canvas. Think of a configuration as the blueprint for the app, version it carefully, and keep notes on what each one targets so future you can tell them apart.
Tabs and screens you can customize
The builder works at two levels: tabs and screens. Tabs are the top-level navigation a worker taps, such as a schedule tab that lists today's appointments or a search tab for looking up records. You decide which tabs appear and in what order, so the most-used view sits where a thumb reaches first. Reducing taps to the daily schedule is one of the cheapest productivity wins available. Screens are the detail views behind each record. The Work Order Overview Screen is the headline example, and you arrange fields, related lists, and components on it to match how a job actually runs. Mobile real estate is tight compared to a desktop record page, so the builder is really an exercise in trimming. Put the parts, the customer signature, and the completion action near the top, and push reference fields lower. A screen that mirrors the technician's task order saves a few seconds on every visit, and those seconds compound across hundreds of appointments a week.
Quick Actions, Global Actions, and Flows
Actions are how a worker does something rather than just reads. The builder surfaces Quick Actions and Global Actions in the app, and you choose which ones appear on each screen. Common patterns are familiar to any field team: mark an appointment complete, capture a signature, take a photo, add product consumed, or create a follow-up work order line item. You can also let workers create product requests when they run short on stock in the van. Flows extend this further. You add a screen flow to the app, then launch it from an action so a worker walks through a guided form such as a safety checklist or an inspection. Flows run on the device and respect the offline model, which means a worker can complete one in a basement and let the result sync later. Order your actions deliberately in the builder. The action a technician taps twenty times a day belongs at the top of the list, not buried three rows down where it costs a scroll on every job.
App Extensions and custom components
When a standard action is not enough, App Extensions open the door to other tools. An extension can point to a URL, launch a native iOS or Android app, or open another Salesforce app, all from inside the Field Service mobile app. A technician might tap an extension to open a mapping app for navigation, start a video call with a remote expert, or pull up a manufacturer portal. The handoff passes record context so the target tool knows which job is in play. For bespoke interfaces, the app supports custom Lightning Web Components. A developer builds a component once, targeting the Field Service mobile surface, and you place it on the relevant screens through the builder. This is how specialized work ships: a complex pricing calculator, a guided diagnostic tree, or an inspection form with conditional logic that a plain field layout cannot express. The split is clean. Developers own the component code, and admins own where it appears and for whom, so each side can move without stepping on the other.
Offline priming and sync behavior
Field Service workers often lose signal, so the app is built to run offline first. The records a worker needs are primed to the device ahead of time, typically the day's service appointments plus their related work orders, assets, and contacts. The configuration you publish influences what shows up offline, because the app can only display fields and components that are present on the primed screens. A field left off the layout is one less thing to sync and store. When a worker is offline, actions queue locally and push to Salesforce once a connection returns. Photos, signatures, status changes, and flow results all wait their turn. This is why offline testing matters more than it looks. Simulating no signal in a sandbox is not the same as a technician in a steel-framed basement with intermittent coverage. Walk the real route with a real device before rollout, watch what fails to load, and adjust the configuration so the essentials are always available even when the bars drop to zero.
Branding, notifications, and per-profile rollout
The app accepts your brand. You set a logo, key colors, and a background image so the tool a worker carries looks like the company's own product rather than generic Salesforce. Branding is a small lever with an outsized effect on adoption, because workers trust a tool that feels built for them. Push notifications round this out: you can alert a worker when an appointment is dispatched or when the schedule shifts, so changes reach the field without a phone call. Per-profile rollout is the thread that ties the builder together. Because you assign configurations by user profile, you can pilot a new screen with one crew, gather feedback, then widen it once it holds up. Start with one configuration per role rather than a single layout for everyone. A plumber, an electrician, and a customer-installer carry different tools and follow different steps, and a screen tuned to each beats a compromise that fits none. Iterate in the first month, because mobile UX is hard to get right on the first try.
Configure a Field Service mobile app configuration
The builder configures the existing Field Service mobile app rather than creating a new object. You draft a configuration on the canvas, then publish it to reach workers. Here is the core path an admin follows.
- Open the builder
From Setup, search for Field Service Mobile App Builder in the Quick Find box and open it. Field Service must be enabled, and you need the right permissions to edit configurations.
- Create or clone a configuration
Create a new configuration or clone the default one to start from a known-good layout. Give it a clear name that signals which role or crew it targets.
- Build tabs and screens
On the canvas, set the tabs a worker sees and arrange fields, related lists, actions, and components on screens like the Work Order Overview Screen. Trim to what the task actually needs.
- Add actions, flows, and extensions
Place Quick Actions and Global Actions, add any screen flows, and wire up App Extensions for URLs or native apps. Order them so the most-used action sits at the top.
- Assign by profile and publish
Assign the configuration to the relevant user profiles, then publish. Workers receive the changes on their next sync.
Top-level navigation such as schedule and search tabs; you choose which appear and their order.
Record detail views like the Work Order Overview Screen, where you arrange fields, related lists, and components.
Quick Actions, Global Actions, and screen flows surfaced on each screen for tasks like signature capture or completion.
Links to a URL, a native iOS or Android app, or another Salesforce app, opened with record context.
Logo, key colors, and background image so the app reflects your company identity.
- Changes do not reach workers until you publish the configuration, so test on a draft first.
- Fields and components only display offline if they are on a primed screen; test with real network conditions.
- One configuration for everyone rarely fits; assign per profile so each role gets a relevant layout.
Prefer this walkthrough as its own page? How to Field Service Mobile App Builder in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Field Service Mobile App Builder.
Hands-on resources to go deeper on Field Service Mobile App Builder.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Field Service Mobile App Builder let an admin configure?
Q2. Which Cloud product family does Field Service, configured by the Mobile App Builder, extend?
Q3. Which targets must a custom Lightning Web Component declare to render inside the Field Service mobile app?
Discussion
Loading discussion…