# How to enable offline access for the FSL mobile application The Field Service mobile app is offline-first. Decide what the technician must have with no signal, and what happens when two people edit the same work order before sync. **Published:** 2026-04-14 **Canonical:** https://synconai.com/offline-access-fsl-mobile **Author:** SynconAI Architecture Team ## In short The Field Service mobile app for iOS and Android is offline-first. Decide the briefing pack a technician must have with no signal: the work order, the skills, the parts, and the customer for that visit. Agree what happens when two people edit the same work order before sync. Do not promise live GPS in a basement. The hub is Agentforce Field Service and Operations. ## Sources - **Field Service Mobile App** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > The Field Service mobile app for iOS and Android is an offline-first, all-in-one tool optimized for a modern mobile workforce. - **Agentforce Field Service and Operations** (retrieved 2026-10-10) https://help.salesforce.com/s/articleView?id=service.fs_overview.htm&type=5 > Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce. ## What to take away - The app is offline-first on iOS and Android. Design for no signal, rather than hoping a toggle will invent coverage. - The briefing pack is the work order, the required skills, the parts, and the customer details for that visit. If it is not on the device, it does not exist on site. - Two people can edit the same work order before either syncs. Write the rule for that clash before it happens in a car park. - Do not promise live location in a basement, a plant room, or a paddock. The schedule was the location. The phone may not update it. ## The guide The note was on a desktop related list. The technician was in a concrete plant room with no signal, and the pump in front of them was not the pump in the note. They phoned. The call did not connect. They did the job they could see, and the dispatcher, who had rescheduled the appointment while the phone was offline, overwrote the completion when the device finally synced. The customer was told one thing. The record said another. Nobody had written down which edit wins. People still search for how to enable offline access on the FSL mobile app. FSL is Field Service Lightning. The help page does not describe offline as an extra you switch on for keen users. It describes the app itself. "The Field Service mobile app for iOS and Android is an offline-first, all-in-one tool optimized for a modern mobile workforce." Offline-first means the normal day includes no signal. The hub around it is named in the same overview: "Agentforce Field Service and Operations (formerly known as Field Service) gives you a powerful, highly customizable, mobile-friendly field service hub in Salesforce." ## The briefing pack List what the technician must be able to read and update with the phone in aeroplane mode. At minimum: the work order, the customer and where they are going, the required skills so they know why they were sent, the parts they are supposed to have, and the tasks on the job. Preferences that change the visit, such as access instructions, belong in that pack. A note that lives only on a desktop related list will not be there when they need it. If a fact is required to finish the job, it has to be on the device before they leave coverage. That is a design task, not a speech about finding better signal. Walk a real job with a technician and turn the radio off. Every time they say they would normally look that up, you have a hole in the pack. Fill the hole on the work order, or accept that the job cannot be finished in a basement. Do not leave the hole and call it user error. The parts list is the usual hole. It sits on a document the office can see and the device never downloaded. The skill is the next hole. They were sent, and they cannot see why, so they cannot tell a site supervisor why they are the right person. The tasks are the third. A template that lived as a PDF on a share drive is stationery. The steps have to be on the record that syncs. Duration is not something they need to admire, but the status they set has to be storable offline, including cannot-complete and the reason. Do not pack the entire organisation. A phone full of every open work order in the company is slower, riskier, and useless in a basement. Pack today's work and the context that job needs. Tomorrow can arrive when they have signal, or the night before if you have decided they must see it tonight. A download of the whole country queue is not a briefing. It is a copy of a book they are not allowed to browse, carried into a place where you cannot see them browsing it. ::: warn Offline is not a reason to widen sharing. What syncs is what they could open online. Contractors in particular should not carry records they are not allowed to see when they are back on the network. Test with their user. An administrator's phone will pack the world, and the test will lie. ::: ## Two editors, one work order The dispatcher can change the appointment while the technician, out of coverage, is updating the same work order. Both edits are honest. They will meet when the phone syncs. Decide the rule before that morning: which fields the technician owns once they have started, which fields the dispatcher still owns, and what a clash looks like to a person. A silent overwrite will destroy either the status the technician set or the reschedule the dispatcher promised the customer. Write it in a sentence the crew can repeat. For example: once the visit has started, the technician's completion notes stand, and the dispatcher does not move that appointment without a phone call. Your sentence may differ. The failure mode is having no sentence, then discovering the result in a car park and calling it a bug. The car park is too late. The customer has already been told a time the record no longer holds, or the record has lost the fact that the job could not be completed. Name the fields. Completion status and notes: the person on site, once they have started. The window and the assigned person: the dispatcher, until the visit has started, and only with a call after that if the customer must be told. Parts consumed: the person on site. A new emergency bump: the dispatcher, who then owes the bumped customer a corrected window. Appointment Assistant can send that correction. It cannot invent the rule about whose edit stands. This page will not invent the app's conflict behaviour. Salesforce's overview says the app is offline-first. It does not, in the lines we are using, publish a merge story. Test with two people and one work order, on a device that has been offline, and see what your org actually keeps. Then tell the crew the result in the same sentence as the rule. If the test shows a silent overwrite, the process has to avoid that overwrite, because hoping the product will change its mind mid-visit is not a design. ::: note Run the clash test before go-live, with a real work order and a device that syncs late. Write down which fields survived. If you did not write it down, you do not have a rule. You have a memory of a demo. ::: ## What not to promise Do not promise live GPS in a basement, a lift shaft, a plant room, or a rural dead zone. The day was planned in the office from location and travel time already stored. The scheduling optimizer accounted for those when it built the route. The pin on a dispatcher screen may be the last location the device could send. Say that out loud, or someone will page a technician who looks close and is actually underground on another job. The stale pin is worse when an emergency is looking for the nearest van. Closeness on the screen is not closeness in the building. Call the person. Do not drag them off a job they have started because a dot looks convenient. Skill and territory still apply underground. A missing signal does not waive the ticket. The emergency policy that breaks the day has to break it with a person you have actually reached. A third-party map that goes blank without signal is the same class of promise. The app is offline-first. A navigation layer that needs a radio fights that. Test it in aeroplane mode on a real appointment. If the tile is empty, keep it off the critical path. What you already have on the console, and why this page will not rank map vendors, is in [third-party mapping](/mapping-integrations-field-service). The briefing pack still has to work when the tile does not. | Must work with no signal | Must be decided before the first clash | Do not promise | | --- | --- | --- | | Today's work order, customer, and where they are going | Which fields the technician owns once the visit starts | Live GPS in a basement, a plant room, or a paddock | | Required skills, parts, tasks, and access preferences | Which fields the dispatcher still owns | A map tile that dies in aeroplane mode | | The ability to set status and notes on that job | What the crew sees when both edits meet | Every open job in the company, on a contractor's phone | | The pack downloaded before coverage drops | A test you have written down | That an administrator's trial is the same as their user | ## Enable means the test passed Enable, in practice, means four things are true. The pack is defined. Sharing is no wider than it is online. The clash rule is written and has been tested on a late sync. A technician has finished a real job with the device offline, including a job that went wrong, so cannot-complete was stored without a signal. Until that test passes, you have not enabled offline. You have installed an app that was already willing to try. Switch the radio off and watch them work. Every lookup, every shrug, every phone call that fails is a missing line on the work order. Add the line, or stop sending that job into the dead zone until the line exists. Do this with a contractor as well as an employee. Their pack should be smaller. Their clash rule is the same rule, on their user, because their appointment is still a work order two people can edit. A separate, vaguer rule for outsiders is how their completion notes get overwritten first. They are the people most likely to be offline at the edge of a patch, and the people whose login was most likely borrowed. Their own user is part of the offline design. A shared login cannot tell whose notes synced. The morning after a dead-zone day is part of the test. The technician's status should be the one they set on site. The dispatcher's window should be the one the customer was told, or the clash should be visible enough that a person fixes it before the next appointment is promised. If you discover the damage only when the customer calls, the rule is too quiet. Make the clash a thing a dispatcher sees on arrival, in the same place they already look, not in an error email nobody owns. Also check what never synced. A completion that stayed on the device because the app was force-closed, or because the pack was too large and the sync gave up, is a job the office thinks is still open. The optimizer may offer that person more work. They are still on the first job, or they have gone home believing it was finished. Small packs sync. A phone carrying the country's work orders is how the sync becomes the outage. Cut the pack back to the visit. Agentforce Field Service and Operations is the hub. Field Service Lightning is the phrase in the search. The mobile app is offline-first on iOS and Android. Treat no signal as the normal day. Pack the visit. Decide who wins the edit. Refuse the live dot underground. That is the enablement. A setting named offline, left at its default while the notes stay on a desktop list, is not. ## Questions ### Is the Field Service mobile app able to work offline? Yes. Salesforce says the Field Service mobile app for iOS and Android is an offline-first tool. Treat no signal as a normal day, not as a mode you enable for keen users. The work is deciding what must be on the device before coverage drops, and proving a technician can finish a real job with the radio off. Installing the app is not that proof. A setting left at its default, while the notes stay on a desktop related list, has not enabled anything the basement can use. ### What should be on the device with no signal? The work order for the visit, the customer and where they are going, the required skills, the parts, the tasks, and the preferences that change access. If a fact is only on a desktop screen, it will not be there on site, and a phone call from a plant room often will not connect either. Walk a real job and switch the radio off. Every lookup is a hole. Do not pack every open work order in the company. Today's visit is the pack; offline is not a reason to widen what a contractor is allowed to see. ### What if the dispatcher and the technician both edit the work order? Decide in advance which fields each of them owns after the visit starts, and test it with a device that syncs late. A silent overwrite will destroy either the completion the technician set or the reschedule the dispatcher promised. The overview does not publish a merge story for us to assume, so the test is the source of truth in your org. Write the result in a sentence the crew can repeat. If you discover the clash only when the customer calls the next morning, the rule is too quiet. Make it visible where the dispatcher already looks. ### Will the office see live GPS from a basement? Do not promise that. Underground, plant rooms, lift shafts, and rural dead zones often have no signal, so the last location received can be stale. Paging the dot will drag someone who is not where the screen says. The day was planned with location and travel time, and the phone is not a live tracker underground. Call the person. Skill and territory still apply, and an emergency does not waive the ticket because the pin looks close. ### What is the product name? Agentforce Field Service and Operations, formerly known as Field Service, described as a mobile-friendly field service hub. FSL means Field Service Lightning, the older search phrase. The mobile app on that hub is offline-first for iOS and Android. Enablement is the briefing pack, sharing no wider than online, a tested clash rule, and a real job finished with no signal. Until those are true, you have installed an app that was already willing to try. Switch the radio off and watch the work; that is the test. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Field Service (https://synconai.com/salesforce-field-service).