The short answer
Every action is stored first on the device, in an encrypted local database, then sent to Business Central in order when the connection returns, with the time it really happened.
The problem is not the outage
Plant networks drop. A forklift clips an access point, a switch reboots after a power dip, a cloud service has a bad hour. The outage itself is rarely the problem. The problem is what operators do next. If the screen freezes, they write on a paper traveller and someone types it in at the end of the shift, and now the data you wanted live is a day late and has the wrong times.
An offline-first app reverses the order of work. The device is not a window onto Business Central that goes dark when the line is cut. It is a working application that happens to synchronise with Business Central when it can.
What is stored
When an operator starts an operation, pauses it with a downtime reason, resumes it, or completes it with good and scrap quantities, the app does not call Business Central first. It writes the action to a local database on the touch PC. That database is encrypted, so production data on the device is not left lying around in plain form.
Each stored action carries the time the operator actually did it. This matters more than it sounds. If the action were stamped with the time it reached Business Central, a twenty-minute outage would turn a start and a pause into two events a second apart, and the run minutes on the operation would be wrong.
What is sent, and in what order
When the connection returns, the app sends the stored actions to Business Central in the order they happened. Order matters because an operation has a life: it cannot be completed before it was started, and a pause has to come before a resume. Sending in order means Business Central sees the same story the operator lived, and the operation log shows the real start, pause and finish times.
- StoreThe action is written to the encrypted local database before anything else
- QueueIt waits, in order, while the connection is down
- SendWhen the connection returns, queued actions go to Business Central one after another
- PostBusiness Central records each one with the time it really happened
Why a retry never double-posts
Networks fail halfway. A command may reach Business Central, the reply may be lost, and the app will not know whether to try again. If the app sends again and the system treats it as new, you have posted two completions and the scrap twice.
The commands are idempotent. Sending the same command a second time has no further effect, so the app can retry as often as it needs to. For finance this is the property that matters most. It means the offline queue can be as clumsy as the network is, and the ledgers still balance.
In our offline test, four commands were queued with the connection down, the app was restarted, and all four were sent in order with the operator's own times. The restart is the important part: the queue lived in the local database, not in memory.
Who is allowed to send
Working offline does not mean working without identity. Operators sign in with Microsoft Entra ID, so the people who can use the shop-floor app are the people you already manage. Devices do not hold a shared password in a settings file. A device uses a certificate and holds only the permissions it needs, so a station that only needs to report operations is not given more than that.
What the ledger shows
After catching up, the picture in Business Central is the same as if the network had never dropped. The operation log has the real times. Output and scrap post to the capacity and item ledgers when the operation completes. The supervisor's role center shows running and paused operations and the Needs Attention list, and rejected commands appear as a cue, so a command that cannot be applied does not vanish quietly.
What you do not get is a live view while the network is down. The manager looking at the role center sees the last information that arrived. That is a limit of physics, not of design, and it ends when the connection returns.
What to test on your own network
Do not take our word for it. Run the same drill on your own plant, with a sandbox and a spare device, before you go any further.
- Start an operation, then switch the network off at the device.
- Pause with a downtime reason, resume, and complete with good and scrap quantities.
- Restart the app while the network is still off.
- Switch the network back on and watch the order in which the actions arrive.
- Compare the times on the operation log with the times the operator actually acted.
If the times differ, or an action arrives twice, you have found the thing worth knowing before you commit.
In Business Central
The features involved are the operation log, the role center cues for running and paused operations and rejected commands, the Needs Attention list, the capacity and item ledgers, and the API that the shop-floor app uses to send its commands. Production orders must be released, and the app works on their routing lines.
Limits
The desktop app is unpackaged and unsigned, with no installer yet, so it is not offered as a download and we do not promise self-install. The app is in English only. It is built for Business Central online, version 29, and works on released production orders. Our offline test was run in a sandbox with demo data, not in a live plant.
Keep reading
Machine data has its own buffer: read from PLC to production order. To test every claim in this article in front of a vendor, use the 17-scene checklist.
See it on your plant
The best test is to pull the cable yourself. Book the offline demo scenario and we will start an operation, cut the connection, restart the app and show you what the ledger records.