Plant rooms have no signal. Your app still has to work.

Records are primed onto the device while it still has a connection, and the technician then works against that local copy. Anything created or modified offline is stored locally and queued until connectivity returns, at which point it syncs. The critical consequence is that if a record was never primed, it simply is not there — offline is not a mode the app enters, it is a set of data that was deliberately put on the device in advance. Deciding what gets primed, and over what horizon, is the central design decision of a mobile rollout.

Yes, using Lightning Web Components, and this is where most mobile projects acquire their worst defects. A component only works offline if it was built for offline, using data access designed to function without a connection. A component that queries live data will work perfectly on a developer's desk and fail silently in a plant room. Some capabilities — camera, barcode scanning — also cannot be properly verified in a browser at all, so they need testing on real devices. We build mobile components offline-first and test them on genuine low-signal sites rather than in aeroplane mode.

Something has to win, and you should decide what rather than discovering it. A technician working offline for three hours while a dispatcher edits the same record online produces a genuine conflict at sync time. The design questions are which fields the field owns outright, which the office owns, whether a conflict should be flagged to a human instead of resolved automatically, and whether the technician is told their change was overwritten. Left undefined, the platform picks a winner nobody chose and field data quietly disappears — which is how organizations lose confidence in their own completion records.

Make it faster than what they do now, and make sure it never fails them in front of a customer. Adoption problems are almost always design problems wearing a training costume: forms that are too long, data that is not primed, components that break without signal. We pilot with a sceptical group rather than an enthusiastic one, because the enthusiasts will make it work regardless and tell you nothing useful. A visible feedback loop matters too — when technicians see a complaint produce a change in the app within a fortnight, they start reporting problems instead of working around them.

Yes, and it is one of the highest-value things to configure properly. A service report generated from the debrief, signed by the customer on the device and sent before the technician leaves, closes the paperwork loop at the job rather than at the depot. It also removes a common billing delay, because the document that finance and the customer both need already exists. The design work is in the template — what the customer sees, what is required before it can be produced, and how it behaves when the report is generated offline and sent later.

Both work technically, and the decision is usually about control rather than capability. Company devices give you a known operating system baseline, predictable storage for primed data and offline images, and a device management route — which matters more than people expect, because offline caching and photo capture are storage-hungry. Personal devices lower cost and friction but introduce a wide spread of hardware ages and available storage. Whichever you choose, assess the actual fleet before design rather than after, because the oldest device in real use sets the performance floor for everyone.