Guide
Offline Field Software Works When the Conflict Rules Are Agreed in Writing Before the Build
Software that works without a connection must decide what happens when two people change the same job. We settle those business rules first, then build and test on a poor connection.
4-minute read4 November 2026
In Brief
- Offline working is usually specified as a feature and scheduled late, by which point the data model assumes a server is always there. Conflicts then reach customers as lost work.
- We see four actions: choose the grade of offline you need, record work as separate entries where possible, write a conflict rule for each job type, and set limits on time away from signal.
- Thinqmesh builds one app for iPhone and Android that keeps working without signal and catches up later. Four weeks cover one field job, with its conflict rules agreed before the build.
The requirement usually arrives as a single line: the application must work offline. It reads like a feature, and it is often scheduled like one, somewhere after the main screens. By then the data model assumes that a server is always available to say what is true, and that assumption is expensive to remove.
Conflict Rules Belong to the Business
Once two people can change the same record without seeing each other, the software has to decide whose work survives. Technology can apply that decision, and it should not be the one making it. Each type of data needs its own answer: two engineers accepting the same job, the last spare part issued twice, a price changed at head office while a salesperson quotes the old one in a basement.
We agree those rules in writing, by job type, before the build, and then test them on a genuinely poor connection as well as in the office. Much field work can also be designed so that conflict does not arise, by recording each finding as its own entry. That question saves more money than any later technical choice.
Four Decisions That Make Offline Working Dependable
Each one is a business decision first, and each is far cheaper to settle before anything is built.
Choose the Grade of Offline You Need
Reading, capturing and shared editing differ greatly in cost.
Reading a manual or a job sheet without signal needs a local copy, and nothing can conflict. Capturing new findings and photographs for later upload rarely collides. Shared editing of the same record while disconnected is where the cost and testing concentrate, so confirm that the work really needs it.
Get started
- List the tasks your field team does without signal.
- Mark each as reading, capturing or shared editing.
Record Work as Separate Entries Where You Can
Two inspectors visiting the same asset can each add a finding, and nothing collides.
Much work specified as shared editing can be redesigned as capture. Each finding, reading or completed step becomes its own record, and the office assembles the picture afterwards.
Get started
- Take one shared record your team edits in the field.
- Sketch it as a series of separate entries.
Write a Conflict Rule for Each Job Type
Letting the latest change win is the absence of a rule, and device clocks cannot be trusted to order events.
For each type of data, choose to merge, to give authority to a role, to reject with an explanation, or to hold for a named reviewer. Anything touching money, safety or a legal record belongs in the last group. The rule decides whose work survives, so it belongs to the business.
Get started
- For one job type, write what happens when two people edit it offline.
- Ask a supervisor whether the outcome is acceptable.
Set Limits on Time Away From Signal
A permission can be withdrawn while a device is out of contact.
Decide how long a device may stay disconnected before it must synchronise, and what is required if one is lost with unsent work on it. Agree which actions need a live check and cannot be done offline at all.
Get started
- Choose a maximum offline period and write it down.
- List the actions that must wait for a connection.
How Thinqmesh Solves This
We answer the decisive question in writing before the build: what happens when two people change the same job offline. Then we build and test against it.
- Week 1
One Field Job, in Detail
We take one job your field team performs and establish what they do, where, and what they record it on today.
- Week 2
Conflict Rules in Writing
Rules for conflicting changes are agreed by job type and recorded before the build begins.
- Week 3
Built for No Signal
One app for iPhone and Android holds what it captures without signal, and uses the same system, logins and permissions as your other software.
- Week 4
Tested on a Poor Connection
The app is tested on a genuinely poor connection as well as in the office, so you know in advance what happens to each change.
You finish with one field job in the app, rules your leaders have agreed, and publication under your own store accounts, planned around Apple and Google review times.
