Offline Use

Inventory Pro Mobile is designed around a connection that comes and goes. The app keeps a copy of frequently used data on the device and holds stock operations in a queue when a request cannot reach the server. When connectivity returns, the queue is submitted in the order the work was captured.

The offline queue and the reference-data cache are separate systems. The queue stores work you performed (receives, issues, moves, cycle counts). The cache stores reference data used to do that work (items, locations, customers, and so on).

Working Offline

The following work can be performed from the queue and cache without a connection:

Capability	How it works
Capture stock transactions	Receive, Issue, and Move forms store work directly to the on-device queue when offline, and submit it automatically later
Pending TX staging	Lines collected in the staging area stay on the device; the whole set can be submitted when connected
Cycle counts	Count updates queue and submit as a batch when connectivity allows
Item search	Search reads the cached item/inventory data set and overlays any queued work so results reflect what you have been doing
Reviewing the queue	The Pending TX panel entry and the Unsent Transactions screen show what is waiting to be sent

A badge in the header shows how many transactions are waiting. Tapping the connectivity icon shows connection status, the queued count, and any reference-data updates that failed and will retry on reconnect.

What Requires Connectivity

These operations always need the server:

Logging in and any new user session
Downloading the reference-data cache the first time, or after a logout or cache reset
Live lookups and reports — orders, purchase orders, picking/packing lists, deliveries, audit trail, error log, edit lists, and images
Final submission of the queue — the device must reach the server to post queued work
Receiving updates from other users — queued work syncs only when the connection returns; the app does not merge other users’ changes while offline

The app shell itself is cached after the first successful visit, so a device that was used online can reopen the app and review or queue work during a later outage. A device that has never completed a visit and cache download has nothing to work from.

How Long the Queue Lasts

The queue is stored in the device browser’s local storage, not on the server. It is not a session cache:

Survives app reloads and browser restarts — closing or restarting the device does not clear it
No expiry — the application sets no time limit or automatic purge on queued transactions
Survives a normal logout unless your site is configured otherwise — some deployments enable a Clear Queue on Logout option, which discards the queue at sign-out; confirm with your administrator
Survives logging in as the same user again — work captured under an account is kept for that account in the browser

What does clear the queue:

Settings > Clear Transactions
A Clear Queue on Logout configuration at sign-out
Clearing the site’s browser storage or data manually

The reference-data cache is different: it is cleared at logout and at a new login so each user starts from a clean, permission-correct dataset.

How Much Can Be Queued

The application places no limit of its own on queue size — the transaction counter keeps increasing and no row cap or purge is applied. The practical limit is the browser’s local storage quota for the site. When the queue shares storage with a large data cache, filling the quota causes writes to fail, so very large offline sessions can hit device limits.

Keep the queue-sized work under control: submit regularly when connected, and use Settings > Clear Transactions to discard abandoned work.

How Synchronization Works

On a connection that is working normally the app checks in about every two minutes with what it calls a beacon. That beacon also gives the queue its cue:

A beacon proves the server is reachable.
Waiting transactions are submitted one at a time, in the order they were captured (oldest first).
Each successful submission moves the queue forward.
If a connection drops mid-submission, the interrupted item is returned to the queue and the rest wait their turn.

Sudden drops are handled deliberately. The app reacts to an offline event after a short delay, shows an offline indicator, and keeps the badge count. When the connection returns, it waits a few seconds to make sure the connection is stable, then retries any failed reference-data loads and resumes the queue.

Writing a transaction offline is usually handled at the form itself. For screens that do not pre-check connectivity, the attempt fails silently and the transaction is placed back in the queue — the result is the same: the work waits on the device.

Ordering and Duplicates

The queue is per device, per user. Transactions sync in capture order and are submitted from one device at a time. This means:

Two devices used by the same or different users do not see or coordinate each other’s queued work — whichever device submits later may do so against stock created by the other
A submitted transaction is removed from the device queue, but the server performs no duplicate check — if the device never sees the server’s confirmation (for example, the connection drops right after the server records the work), that transaction can be submitted again on the next sync
There is no conflict detection between overlapping offline edits from different users; later-submitted changes do not warn about earlier ones

Cycle-count submissions double-check the on-device queue before starting a batch so the same count is not sent twice from the same device.

For accurate results: sync and confirm one device’s work before another device edits the same stock, and re-verify any transaction whose confirmation dialog never appeared.

What Data Is Cached

Reference data is stored on the device in the browser’s offline storage. The cache covers the standard working sets: items and item descriptions, on-hand inventory lines, locations, units of measure, reason codes, warehouses, customers, suppliers, employees, search formats, serial numbers, RFID lookups, configuration values, and the system objects needed by enabled modules (orders, purchase orders, cycle counts, deliveries, assets, jobs, and so on).

Cached sets are named by the data they hold. Warehouse-specific sets (items, inventory lines, orders, purchase orders, cycle counts, quick orders) are kept per warehouse, and screen formats per user.

While connected the app keeps the cache current:

Item/inventory line data is revalidated against the server about every 5 minutes using a lightweight checksum, and is reloaded if the server’s data changed
Warehouse-specific data refreshes about every 15 minutes
Shared/user data refreshes about every 30 minutes
On a page load after a long gap (about an hour without a download) the full data set is refreshed

The on-screen image and stylesheet files are cached separately by the browser’s service worker so the interface itself loads quickly and can reopen offline.

Device and Browser Requirements

Inventory Pro Mobile runs in a modern web browser on iOS (iPhone/iPad) and Android phones, tablets, and barcode scanners. Chrome and Firefox are the recommended browsers.

The main app build uses current JavaScript features, so the most recent few browser versions are expected. Browsers that cannot run the main build automatically switch to a compatibility build targeting older browser generations (roughly 2018-era browsers and newer) and show a Compatibility Mode notice advising an update.

Device-level requirements:

HTTPS — the offline shell (service worker) and the camera scanner require a secure connection
Camera scanning — requires a browser with camera access (getUserMedia) and works over HTTPS only
Storage — the app needs browser storage for the queue and the data cache; cleared browsing data or a full storage reset starts the download and queue process over

Boundaries

Queued work is not stored on the server until it syncs; the device must reach the server to submit it.
The queue is not a multi-user collaboration layer — ordering and duplicates are managed per device.
The reference cache is cleared at logout and at a new login; plan syncs before signing out.
Offline capability depends on a device that has previously completed a cache download while connected.