Many systems are designed on the assumption that an internet connection is always available. But that assumption doesn’t hold through the whole working day everywhere: in a remote branch, in a warehouse, or when the network fails or the power goes out. When the system stops during an outage, sales stop, and transactions pile up on paper, only to be re-entered later, errors and all.
A system that works offline does its core work on the device itself, saves transactions locally, and then syncs them with the central server when the connection returns. The employee keeps working, and the system takes care of the rest.
In markets where a company’s branches are spread across different cities and sites, working offline becomes part of the design of any branch system or field app. It’s a decision made before development, not a feature added at the end of the project, because it affects how data is saved, numbered, and synced.
What must work offline
Not every operation needs to work offline, and building that for everything adds complexity with no justification. Start from the work itself and ask: what can’t wait? The answer is often close to this list:
- Making a sale and issuing the customer’s receipt.
- Recording cash collections.
- Receiving goods and recording inventory movements.
- Stocktakes in the warehouse or the branch.
- Looking up prices and item data stored on the device.
Consolidated reports across branches, central approvals, and changes to the main price list, on the other hand, can usually wait for the connection to return. When this split is written down and agreed on, every employee knows what they can get done during an outage and what they must put off.
Suppose a trading company has several branches and a central warehouse. In a branch, selling, issuing receipts, and recording cash must continue whatever happens to the connection, and in the warehouse, receiving and stocktakes must continue. Approving large discounts and transferring goods between branches, on the other hand, can wait for the connection to return, because both need head office approval anyway.
Local storage and sync
To work offline, a device needs a local copy of the data it uses: items, prices, customers, and the branch’s inventory balances. Each transaction is saved to a database on the device as soon as it’s entered, not held in temporary memory, so nothing is lost if the device suddenly shuts down.
Then comes sync, which is where the real difficulty lies. Saved transactions are sent to the server in order through a queue, and sending is retried until the server confirms it has received them. The server must also recognize a transaction if it arrives twice, so that it doesn’t record it twice.
In the other direction, the device receives what has changed centrally: new prices, added items, and balances updated by other branches. Deciding what is downloaded to each device, and when, is an important design decision, because loading all the data onto every device slows sync down and widens what has to be protected.
Each transaction is recorded with the time it was actually entered on the device and the time it reached the server, because reports need the first and reviews need the second. The device clock alone isn’t relied on to order transactions across branches, because device clocks may differ or be changed by hand.
Conflicts: when two branches change the same record
Suppose two branches both sold the last unit of the same item during an outage, or head office changed a price while a branch was offline and the branch sold at the old price. When the connection returns, two conflicting changes reach the server, and the system has to know what to do with them.
These are business questions before they’re technical ones, and their answers must be settled before development. Common rules for resolving them include:
- Financial transactions are neither canceled nor merged: a completed sale stands, and the stock shortfall is handled with a visible correcting entry that the person responsible reviews.
- Master data such as prices is owned by head office; anything from a branch that contradicts it is logged, and the person responsible is alerted.
- For some fields, such as a customer’s phone number or address, the latest change wins, and the previous value is kept in the history.
- Anything a written rule doesn’t settle is referred to a designated person for review, and isn’t resolved silently.
Conflict resolution rules are business decisions before they are code, and the business owners must agree on them before the developers write them.
Document numbering and what the employee sees
When two branches issue receipts offline, neither can ask the server for the next number. If all the devices rely on a single global sequence, numbers are duplicated at sync and documents overlap.
The solution is for each document to carry a unique identifier generated on the device itself, plus a visible number that includes the branch or device code and its own sequence. That way, no two documents clash at sync, the number stays clear to the customer and the accountant, and every document can be traced to the branch and device that issued it.
Employees need to know the state of their work without asking anyone. The screen shows clearly whether the device is online, how many transactions are waiting to be sent, and when the last successful sync took place. If a transaction is rejected at sync, it’s shown to them with the reason, and it doesn’t disappear without a trace.
Managers also need a matching view at head office: which branches haven’t synced for a while, and which devices have delayed transactions. A branch that looks quiet on the dashboard may be offline rather than having no sales.
Securing local data and testing outages
Data stored on a device in a branch, or carried by a sales rep, is more exposed to loss or theft than data on the server. So it’s protected in line with its sensitivity: encrypting the local database, not storing passwords as plain text, a sign-in that works offline, and the ability to disable a lost device and block it from syncing. And just as the system decides what is downloaded to a device, it decides what is deleted from it once synced.
User permissions apply on the device just as they do on the server. An employee who isn’t allowed to give a discount or cancel a receipt while online isn’t allowed to do so during an outage either, and the device keeps a log of every transaction and who performed it, which is sent to head office with the sync.
As for testing, it isn’t enough for the system to work while the network is connected. Disconnect a device in the test environment for hours of simulated work, then reconnect it and watch: did the transactions appear at head office exactly as they were, with nothing duplicated or missing?
Also try shutting a device down in the middle of a transaction, losing the connection in the middle of a sync, and editing the same record from two devices, then check the result in each case. These scenarios reveal before launch what a real outage might reveal on a busy working day.
Ideally, employees from the branches themselves take part in these tests, because they know what actually happens during an outage: who prints the receipt, who records the cash, and what gets delayed when the branch is busy.
A checklist before development
- A written list of the operations that must continue offline, and those that wait for the connection to return.
- A definition of the data stored on each device, and how long it stays there.
- Conflict resolution rules for each type of data, agreed on with the business owners.
- A document numbering method that doesn’t depend on a connection to the server.
- A sync status visible to the employee, and clear handling of rejected transactions.
- Protection for local data, and a way to disable a lost device.
- Test scenarios for outages, reconnection, and sudden shutdowns.
When the connection drops, work must not stop with it. If your current system stops when the internet goes down, or you are planning a new system for several branches or a mobile app for field work, you can discuss your situation with the ITS team, so that together we can determine which operations must keep running and how their sync is set up.
Related serviceMobile apps