The Device That Has Not Phoned Home
A storekeeper spends Thursday in a warehouse with no signal. Everything they do is sitting on the handset in their pocket. The useful question is not whether that works — it does — but what you can see from the office while it is happening.
Offline capability is sold as a yes-or-no feature and it is not one. The honest version has three parts: which operations can happen without a connection, where the work sits until it reconnects, and what anybody in the office can see about it in the meantime. Most attention goes to the first. The third is where the operational risk actually lives.
The risk is simple to state. Work done offline exists in exactly one place — the handset — until it syncs. A phone dropped in a loading bay on Thursday afternoon takes Thursday afternoon with it. Nothing about that is unusual or badly designed; it is the unavoidable shape of working without a connection. What varies between systems is whether anybody knew there was a day's work sitting on that phone.
What can actually happen offline
Four operations, all on the mobile app, and it is worth being exact because the general phrase "works offline" invites people to assume everything does.
- Raising a stock transfer
- Checking stock out
- Checking stock in
- Recording an asset movement
That is the list. Those four cover the field work that most often happens where the signal does not reach — a storekeeper in a warehouse with a metal roof, somebody moving equipment between sites, a delivery received at a location with no coverage.
And what does not
A stock count cannot be conducted offline. A purchase order cannot be received offline. Dispatch is not offline. And selling is not offline — a till with no connection cannot take a sale. If your requirement is a shop that keeps trading through an outage, that requirement is not met by any of this and you should read offline point of sale, which addresses that question directly rather than adjacently.
The distinction that makes sense of the list: all four are movements of things you are physically holding. You know what is in your hands whether or not you have a signal, so recording it later loses nothing. A count and a sale both need to agree with a shared, current state of the world, which is exactly what you do not have when disconnected.
The screen that watches the fleet
Every device with stock and asset movement captured offline reports on itself — how much is queued, how much has failed, how much has synced, what version it is running, and when it last made contact. That reporting builds a control screen for whoever is responsible for the field.
The summary answers the questions worth asking daily.
| The figure | What it tells you | When to act |
|---|---|---|
| Devices | How many handsets are doing offline work | When it is larger than the number of people who should be |
| Stale devices | Handsets that have not made contact in over half an hour | Any that were expected back — this is the important one |
| Queued | Operations waiting on handsets, as last reported | When it stops falling |
| Failed | Operations the devices could not complete | Any non-zero figure, same day |
| Received and synced today | What actually arrived and landed | When the gap between them is wide |
| Conflicts | Work that arrived and could not be applied | Always, individually — each one is a real decision somebody has to make |
| Rejected on location | Operations refused for a missing or unreliable position | When concentrated on one device or one site |
Individual devices are listed under that with their own queued, failed and synced counts, the app version they are running, and when they last checked in. The operations themselves are listed separately and can be filtered by status and by area of the system, or searched by the reason a particular one did not apply.
The one thing to understand about those numbers
They are last reported. Not current — last reported. A device tells the server how much is in its queue when it can reach the server, which is precisely when the queue is about to shrink.
Follow that through and the consequence is the opposite of what the screen appears to say.
-
A device with a large queue is usually fine
It reported that number because it had a connection. It is very likely draining right now, and the figure is already out of date in the good direction.
-
A device showing nothing queued may be carrying everything
It reported zero when it last had signal, then went into a basement for six hours and did four transfers. The screen still shows zero, because nothing has told it otherwise.
-
So the figure that matters is when it last made contact
A device that has been dark since this morning is the one to ask about. Its queue number is a fact about this morning and tells you nothing about the afternoon.
-
Which makes staleness the alarm, not queue depth
Half an hour without contact is the threshold used to mark a device as stale. On a normal working day, most of them should not be.
A device showing zero queued and last seen at nine this morning is more concerning than one showing forty queued and last seen a minute ago.
This inverts the natural reading of the screen, which is why it is worth saying to whoever will be watching it. The instinct is to look at the big numbers. The information is in the timestamps.
Six things that can happen to an operation
Work that has been queued goes through a small set of states, and three of them need a person.
| State | Meaning | Needs attention |
|---|---|---|
| Queued | Recorded on the device, not yet sent | Only if it stays there |
| Syncing | On its way | No |
| Synced | Applied | No |
| Failed | Sent and could not be completed | Yes |
| Conflict | Sent, and the world had moved on | Yes, and it is a judgement call |
| Discarded | Abandoned rather than applied | Worth knowing why |
Conflict is the interesting state and the reason offline work needs a supervisor rather than just a queue. Somebody records a transfer of forty units at eleven o'clock, disconnected. By the time the handset reconnects at four, somebody else has moved those units. Both people acted correctly on the information they had. The system cannot decide which of them should win, and it should not try.
So it holds the operation, marks it, and makes it findable. Somebody with knowledge of what actually happened resolves it. That is slower than an automatic rule and it is the right trade — an automatic rule here silently produces a stock figure that matches neither of the two things that happened.
Why location rejections are counted separately
Some offline operations carry a position, and some are refused because that position was missing or too vague to be worth recording. These get their own figure on the summary rather than being folded into general failures, which is the correct treatment because they have a completely different cause and a completely different fix.
A general failure is usually about the data. A location rejection is almost always about the building — one warehouse, one basement, one particular bay where nothing gets a fix. Concentrated on a site, it tells you to change the requirement or the process at that site. Concentrated on a device, it tells you the phone is old. Spread evenly, it tells you the accuracy threshold is set tighter than your field conditions support.
What AWRA OpsHub does today
- Four operations that work without a connection, all on the mobile app: stock transfer, check-out, check-in and asset movement.
- A control screen for the fleet — device count, stale devices, queued and failed totals, what arrived and synced today, conflicts, and location rejections.
- Per-device detail including queued, failed and synced counts, app version, platform, last error, and when the device last made contact.
- Every queued operation listed and filterable by state and area, searchable by its identifier, its action, the record it targets, the reason it did not apply, or the person.
- Six distinct states including conflict and discarded, so work that could not be applied is visible rather than lost.
- Location rejections counted separately from other failures, because they have a different cause and a different fix.
- A staleness threshold of half an hour, which is what turns "no news" into a visible figure.
What it does not do
- Counting is not offline. A stock count needs current shared state and cannot be conducted disconnected.
- Receiving a purchase order is not offline, and neither is dispatch.
- Selling is not offline. A till with no connection cannot take a sale. This is the most common assumption and the most important one to correct early.
- The queue figures are last reported, not live. A device that has been dark for a day shows yesterday's number, which is why the contact time matters more than the count.
- No alert when a device goes stale. Half an hour without contact is shown on a screen; nothing tells anybody. The screen has to be opened.
- Conflicts are not resolved automatically, deliberately — but that means an unresolved conflict sits until a person handles it.
- The screen shares a permission with device trust. Anyone who can see offline operations can also lock and revoke devices. There is no view-only role for the fleet on its own.
Not ours, by choice
- We will not resolve a stock conflict automatically to keep a queue clean. Two people acted correctly on the information each had, and picking a winner by rule produces a figure that matches neither of the things that actually happened.
- We will not extend offline to selling or counting because it would demonstrate well. Both need agreement with a shared current state, which is exactly what a disconnected device does not have, and shipping them would move the failure from a refusal at the point of sale to a discrepancy discovered a week later.
Alerting when a device goes stale or a conflict appears, and a view-only permission for the fleet screen separate from the ability to lock devices, are both scope rather than ceilings — the data, the threshold and the notification infrastructure all exist.
If you take one habit from this page: look at the contact times, not the queue depths. A device last seen four hours ago is carrying something you cannot see, and that is the only figure on the screen that behaves the way people expect it to.
A working routine for whoever owns the field
Five minutes, once a day, end of shift
- Look at stale devices first. Any handset that should be back and has not made contact is a conversation today, not tomorrow.
- Check failed operations. Any non-zero figure is somebody's work that did not land, and the person who did it has gone home believing it did.
- Open each conflict individually. These are decisions, not errors, and they need somebody who knows what happened on the floor.
- Watch location rejections for concentration — one site, one device, or spread evenly. Each pattern means something different.
- Glance at app versions across the fleet. A single handset several versions behind is usually the one generating the odd failures.
The end-of-shift timing matters more than the five minutes. The point of the routine is to find work sitting on a handset before the person carrying it goes home, because after that the recovery is a phone call and a request that somebody stand somewhere with signal.
Related: the till side of this question is in offline point of sale, the counting constraint in the count that cannot see the answer, and the device controls that share this screen's permission in the phone that left with the storekeeper.
Our take
Be precise about the four operations when you set expectations internally, because "works offline" is heard as "everything works offline" and the correction is much cheaper before go-live than after. Then give one person the fleet screen at end of shift, and teach them to read the contact times rather than the queue numbers — a device showing zero and last seen this morning is the one carrying your afternoon. Conflicts need a human and that is correct; the thing to build a habit around is that nothing will tell you they are waiting.
See offline operations
Four field operations that work without a connection, a fleet screen showing what is queued and what went stale, and conflicts held for a person rather than resolved by rule.
Explore offlineFrequently asked questions
What exactly works offline?
Four operations on the mobile app: raising a stock transfer, checking stock out, checking stock in, and recording an asset movement. That is the complete list. All four are movements of things somebody is physically holding, which is why recording them late loses nothing. Counting, receiving a purchase order, dispatch and selling all need agreement with a shared current state, so none of them work disconnected.
Can our shop keep selling during an internet outage?
No. A till with no connection cannot take a sale. This is the most common assumption made about offline capability and the most important one to correct before go-live rather than after. If continuing to trade through an outage is a genuine requirement for your operation, that is a specific question with a specific answer, and it is worth reading it separately rather than inferring it from the presence of offline features elsewhere in the product.
How do we know if work is stuck on someone's phone?
The fleet screen shows every device with what it has queued and when it last made contact — and the contact time is the figure to read. The queue numbers are last reported rather than live, so a device that reported zero this morning and has been in a basement since may be carrying a full afternoon. A device that has not made contact in over half an hour is marked stale, and on a normal working day most should not be.
Why is a device with a large queue not the urgent one?
Because it reported that number, which means it had a connection when it did — so it is almost certainly draining right now and the figure is already out of date in your favour. The concerning device is the one showing a small queue and an old contact time, because that number is a fact about the last moment it had signal and says nothing about what has happened since. The instinct is to look at the big numbers; the information is in the timestamps.
What happens when two people move the same stock?
The later operation is marked as a conflict and held rather than applied. Both people acted correctly on the information available to them, and the system does not have the context to decide which should win — so it makes the situation findable and leaves the decision to somebody who knows what actually happened on the floor. That is slower than an automatic rule and it is deliberate: a rule here quietly produces a stock figure matching neither of the two real events.
Will somebody be told when a device goes stale or a conflict appears?
No. Both are visible on the screen and neither notifies anybody, so this needs a routine rather than a reaction. Five minutes at end of shift is enough, and end of shift is the right time — the point is to find work sitting on a handset before the person carrying it goes home, because after that recovering it means a phone call and asking somebody to go and stand where there is signal.
Who should be given access to the fleet screen?
Whoever owns field operations — but know that it currently shares a permission with device locking and revocation, so there is no way to grant a view of the fleet without also granting the ability to sign devices out. In practice that means giving it to a supervisor rather than to everyone who would find it interesting, and being explicit with that person about which of the two abilities they are expected to use.
