What a Scanner Can Answer With No Signal
The server matches a scanned code across fourteen record types. A phone with no signal matches four, on the same identifiers, and tells the operator exactly what it could not check.
- Written by
- AWRA OpsHub TeamOperations Insights
- Issued
- Build
- Initial
There is a tempting way to build offline scanning and it is the dangerous one: match the code against whatever the device happens to have cached, show the record, and let the operator get on with it. It demonstrates beautifully. It also answers confidently and wrongly, which in a stock system is worse than not answering at all.
Wrongly, because a scan is not a lookup. Online, that code goes to a service which matches it across fourteen kinds of record, catches the case where the same string exists in two workspaces, filters the available actions by the operator's permissions and the workspace's plan, and raises the exceptions that stop bad work — the recall, the hold, the quarantine. None of that can be reconstructed from a cache on a phone.
So the offline half does not try. It does the narrow thing completely, and it says out loud what it is not doing.
Four types, not fourteen
What the phone can match alone
- Items — on barcode, stock code, or identifier.
- Assets — on asset code, barcode, serial number, or identifier.
- Locations — on code, barcode, or identifier.
- Warehouses — on code or identifier.
What needs the server
- Purchase orders, requests for quotation, quotations, procurement requests.
- Stock transfers, adjustments, invoices, point-of-sale entries, cash drawers, customers.
- Any check of whether that code exists in more than one workspace.
- Which actions this person may take on it — permission and plan are both server-side.
The identifiers are copied, not invented
Each type is matched on exactly the fields the server matches it on, listed explicitly rather than "any field that looks like a code". That is the difference between an offline match meaning the same thing as an online one and merely resembling it — and a scanner that finds a record offline which the server would not have matched is a scanner that has taught somebody to trust it wrongly.
The search runs in a fixed order — items, then assets, then locations, then warehouses — because that is the order of frequency in the field, and a code can also be typed with its own prefix. Scanning or entering AST-4471 looks in assets and nowhere else, which settles the rare case where a serial number and a stock code collide.
What every offline answer carries with it
An offline resolution comes back in the same shape as a real one, with two additions that the screens above it key off: a flag saying this came from the cache, and the timestamp of the cache it came from.
And a list of limitations that is specific to the type, rather than a generic disclaimer. Each line names a decision the operator might otherwise make wrongly.
| Scanned | What the phone cannot vouch for |
|---|---|
| An item | Stock levels are from the last sync and may have moved. Recall, hold and quarantine status cannot be checked. Anything recorded here is queued. |
| An asset | Custody and location are from the last sync — it may have moved. Approval requirements and GPS policy are checked by the server on sync, not now. |
| A location | Stock held here is from the last sync. Anything recorded here is queued. |
| A warehouse | Stock held in this warehouse is from the last sync. Anything recorded here is queued. |
A scanner in a cold store that can name the item on the carton is worth a great deal, even when it cannot tell you the item was recalled an hour ago — provided it says so.
That sentence is the entire design brief. The second clause is not a caveat attached to the first; it is what makes the first one safe to ship.
The two limitations that are not about staleness
Most of the list above is the ordinary problem with cached data: it was true at the last sync and may not be now. Two lines are different in kind, and they are the ones worth reading twice.
Recall, hold and quarantine cannot be checked. These are not values that drifted — they are the exceptions that exist specifically to stop work, raised by the service the phone cannot reach. An item cached this morning and quarantined at noon looks entirely normal on a disconnected handset. The operator is told that, in those words, at the moment they scan it.
Approval requirements and GPS policy are checked on sync, not now. So a movement captured against an asset offline can be perfectly valid on the device and refused when it lands. Saying so at scan time is what turns that refusal from a surprise hours later into something the person knew was possible when they chose to capture it.
Why a cache has a maximum age
Cached reads are capped at three weeks. Beyond that they are dropped rather than shown, and the phone reports the code as unresolved instead of naming a record it last saw a month ago.
The asymmetry with captured work is deliberate and worth stating: captured work is never discarded on age — a queued movement is held for a person to decide about. A cached read is a copy of something the server already has, so dropping it costs a reload. Confusing those two is how an app ends up either forgetting a shift of work or answering from a cache it should have let go of.
The code resolves and the values look right
Work, and let it queue
This is the ordinary case and the reason the offline path exists at all. The limitations are on screen while you do it.
The item matters and the status might have changed
Note it and check on sync
Recalls and holds are exactly what a disconnected device cannot see. If the decision turns on one, it is a decision to make when there is a connection.
Nothing matched
Trust that over a guess
A code the cache does not know is reported as unresolved. It has not been matched loosely against something that looked similar, which is the failure that puts a movement on the wrong record.
Questions about offline scanning
Does scanning work offline?
What you will hear
"Yes, fully."
How to read it
"Fully" is the answer to be suspicious of. A phone cannot check a recall, cannot see another workspace, and cannot evaluate a permission the server holds. Ask which record types it matches offline and which it does not — a vendor who has thought about it has a list.
What does the operator see when a code resolves from the cache?
What you will hear
"The same as online."
How to read it
Then they cannot tell the difference, which is the problem. An offline answer should be marked as one, dated, and accompanied by what it could not check — otherwise it is a stale record wearing a live record's clothes.
How does the offline match decide what a code refers to?
What you will hear
"It searches the cached data."
How to read it
On which fields? A loose search across everything cached will match things the server would not, and an operator who has been taught that offline scanning finds records will believe the wrong one when it does.
How old can the cached data be?
What you will hear
"It refreshes regularly."
How to read it
That is a description of the good case. Ask what happens on a device that has been away for a month — there should be a stated maximum age after which a read is dropped rather than served.
Our take
Offline scanning is the clearest example we have of a feature that is better narrow than complete. Reimplementing a resolve service on a phone would produce something that looks identical, works most of the time, and is wrong in exactly the cases the service was built for — recalls, holds, cross-workspace collisions, permissions. So the device does four record types on the server's own identifiers, marks every answer as cached, dates it, and names what it could not check. That is less than the online path by design, and it is the version we would defend to somebody whose stock is in a cold store.
The offline matcher is a small surface with obvious extensions
The type list, the identifiers and the limitations are three tables in one file. Each of these is a defined change rather than a new subsystem.
More record types matched offline
Purchase orders and transfers cached for the crews whose work starts by scanning paperwork rather than goods.
Cached exception flags
Recall, hold and quarantine status carried in the cache so a disconnected scan can at least warn on the flags as they stood at the last sync.
Cache ages you choose
Your own maximum age for cached reads, per workspace, for teams whose trips away from a network are genuinely longer than three weeks.
Offline scan history on the device
What was scanned, when, and what it resolved to — readable in the field before anything has synced.
Each addition is bounded by the same rule the current matcher follows: match on the identifiers the server matches on, and say what the answer could not check.
Tell us what your crews scan firstScan a carton in flight mode
The interesting part is not whether the item comes back. It is what the screen tells you about the answer — whether it is marked as cached, how old it is, and what it says it could not check.
Talk to us about scanning offlineFrequently asked questions
Can I scan a barcode with no signal?
Yes, for items, assets, locations and warehouses — the four types the app caches in full for field work — matched on the same identifiers the server matches them on. The answer is marked as coming from the cache, dated, and accompanied by what it could not check. The other ten record types the online service handles need a connection.
Why does offline scanning cover fewer record types than online?
Because the online service does far more than look a code up: it matches across fourteen record types, catches codes that exist in more than one workspace, filters actions by permission and plan, and raises the exceptions that stop bad work. None of that can be reconstructed from a cache on a phone, and building something that resembles it would answer confidently and wrongly.
Will an offline scan tell me an item has been recalled?
No, and it says so at the moment you scan. Recall, hold and quarantine are raised by the service the phone cannot reach, so an item cached this morning and quarantined at noon looks entirely normal on a disconnected handset. If your decision turns on that status, it is a decision to make with a connection.
How does the app know what a scanned code refers to?
By the same fields the server uses: barcode, stock code or identifier for an item; asset code, barcode, serial number or identifier for an asset; code, barcode or identifier for a location; code or identifier for a warehouse. You can also type a code with a prefix — an asset code entered as AST-4471 is looked for in assets and nowhere else, which settles a collision between a serial number and a stock code.
What happens if nothing matches?
The code is reported as unresolved rather than matched loosely against something similar. A near-match on a disconnected device is how a movement ends up recorded against the wrong record, and it is the one outcome that is harder to correct than simply having no answer.
How old can the offline data behind a scan be?
Cached reads are kept for up to three weeks and dropped after that, so the phone reports a code as unresolved rather than naming a record it last saw a month ago. Work you captured is treated the opposite way — it is never discarded on age, only held for a person to decide about, because losing a cached read costs a reload and losing captured work costs a movement.
