Four Things You Can Do With No Signal
The honest answer is four. Not "most things", not "core operations" — four specific operations can be completed with no network and synced later, and knowing precisely which four is the difference between a productive site visit and a wasted flight.
Every cloud system is asked whether it works offline, and almost every answer is bad. "Yes, we cache" and "it syncs automatically" are both technically true statements that leave the person asking no better off, because the thing they actually need to know is not whether an offline mode exists. It is which specific tasks they can complete at a site they have flown to, and what happens to the ones they cannot.
That question is unusually load-bearing across the Pacific. Where sites are separated by sea or by terrain with no road, a visit is planned rather than popped out to, and the whole trip may happen with no connection at any point. That is not the "signal dropped for ten minutes" problem that offline modes are usually designed around. It is a different shape: the entire working session is offline, and reconnection happens afterwards, somewhere else.
So here is the specific answer rather than the reassuring one.
Four operations, named
Four things can be recorded with no network at all, on the mobile app, and will be held and sent when a connection returns:
- A stock transfer — moving stock from one warehouse or location to another.
- A check-out — inventory issued to a person or a job.
- A check-in — inventory coming back.
- An asset movement — the whole set of asset events, which includes assignment, relocation, verification, and marking something lost or damaged.
That is the complete list. There is no fifth, and it is worth stating that flatly rather than leaving it as an impression, because planning a trip around a capability that is not there is an expensive way to find out. What a transfer actually does once it is sent is covered in stock in transit on a long corridor, and the wider multi-site picture in multi-branch stock control.
Two qualifications, both important. This is the mobile app. The web application has no offline mode and none of this applies to it. And the four are all field operations — recording what physically happened to physical things. Nothing approves, nothing purchases, nothing invoices. That is a coherent boundary rather than an arbitrary one: these are the operations that happen where the signal is not.
What you can see, as opposed to do
Reading is considerably better served than writing, which is the right way round for a site visit. Cached and available with no connection: your item list, warehouses and locations, adjustment reasons and units, recent adjustments and their details, stock transfers and their details, your assets and their detail pages, asset custodians, the asset movement history, the asset policy that governs what needs approval, and the custom field definitions that make your own forms render correctly.
That last one matters more than it sounds. If your organisation has added its own fields to assets or adjustments, those definitions are cached too — so a form filled in at a remote site is the same form you would fill in at head office, not a stripped-down version that quietly drops your fields.
Data served from the cache is flagged as such to the interface, so a screen can tell you it is showing you what it last knew rather than what is true now. And the app can be unlocked with no network at all, using a locally held verifier — which sounds like a detail until you have watched somebody be locked out of their own device at the top of a valley.
What happens when you reconnect
This is where offline systems are usually either honest or quietly dangerous, so it is worth walking through.
Every queued operation carries an idempotency key generated on the device when the operation was created. That key is the answer to the oldest problem in offline sync: a request that succeeded on the server but whose response never reached the phone. Without a key, the retry creates a second transfer. With one, the server can recognise the repeat. The mechanism is real and is used on the stock paths, among others.
A queued operation is either pending or failed, and a failed one carries its error message. The design decision worth knowing about is what happens next: a failed operation is not retried blindly forever. It is routed back to the screen it came from, with the payload pre-filled as a draft, so a person opens the form, sees what the server objected to, and decides.
A queue that retries forever is not resilience. It is a system quietly insisting on something a person has not agreed to yet.
That is the right call for this kind of work. A stock transfer recorded three days ago at a site you have now left may fail because the stock is no longer where the device thought it was — and the correct response to that is a human looking at it, not an automated retry that eventually forces it through.
Planning a trip around this
-
Open the app on the network before you leave
The caches fill from use. A device that has not loaded the item list, the asset list or the custom field definitions while connected will not have them at the site. Building "open the screens you are going to need" into pre-departure is unglamorous and it is the single highest-value thing on this list.
-
Plan the trip around the four, and around what is only readable
Counting, moving, issuing, returning, verifying and recording damage all work. Approving does not, purchasing does not, invoicing does not. If a task on the trip plan needs one of those, it needs to happen before departure or after return, and knowing which in advance is the whole point of the list above.
-
Check the queue before you leave the site, not after
The queue and its failures have their own screen, and the dashboard counts pending and failed movements separately. Reviewing the count while still standing next to the thing you were recording costs a minute. Discovering a failure a week later, from an office, means somebody has to reconstruct what they saw.
-
Resolve failures as decisions, not as retries
A failed operation reopens its original form with your data in it. Read the error, look at what has changed since, and re-submit deliberately. The mechanism is built to put a person in that loop; using it as a retry button throws away the only part that was thinking.
-
Do not plan around approvals happening in the field
The asset policy that decides what needs approval is cached, so the app knows a movement will require one. The approval itself is not an offline operation. Where a site visit generates work that needs signing off, expect the sign-off to happen after you are back — and sequence the trip so nothing is blocked waiting for it.
The honest boundary
It would be easy to read the four-item list as thin. Held against what most cloud operational software does when the network goes — which is nothing, followed by a spinner — a durable queue with idempotency keys, cached custom field definitions and a human-resolved failure path is a serious piece of work, and it is pointed at exactly the operations that occur where connectivity is worst.
What it is not is a second, fully offline copy of the product, and no amount of careful wording should be allowed to suggest otherwise. The value of knowing the boundary precisely is that a trip can be planned against it.
What AWRA OpsHub does today
- Four operations that queue offline on the mobile app — stock transfer, check-out, check-in, and asset movement — held on the device and sent when a connection returns.
- A durable queue with pending and failed states, per-operation error messages, and its own screen in settings.
- Client-generated idempotency keys on queued operations, so a retry after a lost response is recognisable as a repeat rather than a new transaction.
- Broad cached reads — items, warehouses, locations, reasons, units, adjustments, stock transfers, assets and their details, custodians, movement history and asset policy.
- Cached custom field definitions, so your own fields render on a form filled in with no network.
- Offline unlock, using a locally held verifier, so a device without signal is not a device you are locked out of.
- Human-resolved failures — a failed operation reopens its original form as a pre-filled draft rather than retrying silently.
- Queued and failed counts on the dashboard, so the backlog is visible without going looking for it.
What it does not do
- No offline mode in the web application at all. Everything here is the mobile client.
- No offline approvals. The policy that decides what needs approving is cached; the approving is not.
- Nothing commercial works offline — no purchase orders, no invoicing, no point-of-sale, no payments.
- No offline reporting. Cached list screens are not reports, and nothing runs a report against local data.
- No background or automatic sync of the queue — reconnection is not by itself a guarantee the backlog has cleared, which is why checking the count is on the list above.
- No conflict resolution beyond the failure path. If the server rejects a queued operation because the world moved on, the resolution is a person re-submitting, not a merge.
What is not built for Papua New Guinea today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Papua New Guinea. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a fortnightly pay cycle, a PNG payroll engine, supplier compliance dates at payment time, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
A pay period that is not a calendar month
The first build here is not a tax pipeline, because there is no clearance regime to connect to — it is a payroll period that can be a fortnight. Today our payroll run is one calculation per organization, per calendar month, per country of work, enforced by a unique key on the table and assumed again in the timesheet lock, the period-end resolution, the attendance window and the run form. Papua New Guinea pays twenty-six times a year and twice a year a month needs three runs, so this is a data-model change rather than a setting, and we would scope it as one. Then salary and wages tax on fortnightly tables, and the statutory deductions, computed on live employee records.
Supplier compliance dates, banks and payments
An expiry-dated compliance status on the supplier record that the payment run actually reads, so a business payment to a supplier whose Certificate of Compliance lapsed last week is flagged before it leaves rather than found in a review — we hold the document today and do not act on it. Plus bank feeds and local payment rails wired into the Payments Register. We do not verify a certificate and never will; validity is the Commission's determination.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Papua New Guinean payroll engine: fortnightly salary and wages tax tables, superannuation and the training levy computed on live records, with the twenty-sixth pay period of the year recorded as its own event rather than folded into a month that already has two.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedIf you run sites that are visited rather than dropped in on, the practical summary is a single sentence: the recording of physical fact works without a network, everything that involves a decision or money does not, and the trip should be planned in that order.
Frequently asked questions
Exactly which operations work with no network?
Four, on the mobile app: a stock transfer, a check-out, a check-in, and an asset movement — the last of which covers assignment, relocation, verification and marking something lost or damaged. There is no fifth. The web application has no offline mode at all.
What can we look at offline, as opposed to record?
Considerably more: items, warehouses and locations, adjustment reasons and units, recent adjustments and stock transfers with their detail pages, assets and their details, custodians, movement history, the asset approval policy, and your own custom field definitions. Screens indicate when they are showing cached data rather than live data.
If sync retries an operation, could it be recorded twice?
Each queued operation carries an idempotency key generated on the device when it was created, which is what allows a repeat submission to be recognised as the same operation rather than a new one. That mechanism is in place on the API and is used on the stock paths. As a matter of practice it is still worth reviewing the queue after a trip rather than assuming.
What happens to an operation the server rejects?
It is marked failed, keeps its error message, and is routed back to the screen it came from with the data pre-filled as a draft. It is not retried indefinitely in the background. That is deliberate — an operation recorded days ago at a site you have left may fail because circumstances changed, and a person should decide what to do rather than an automated retry forcing it through.
Can approvals be done in the field?
No. The policy that determines which movements require approval is cached, so the app knows in the field that an approval will be needed — but the approval itself is not an offline operation. Sequence site visits so that nothing on the trip is blocked waiting for a sign-off that can only happen once you are back.
