Working off the network: how Sentinel handles no signal
What you can read and do without a connection, how the sync queue restarts on its own, and what happens when there's a conflict.
A valley-bottom trail, a mountain sector, a boardwalk under dense canopy: the network isn't where the work is. That's Sentinel's starting constraint, and the app is built around it.
The rule is one sentence: nothing you do in the field waits for the network. You create, you edit, you photograph, you log your time. Everything is written to the phone immediately, and leaves later on its own.
This page explains the whole mechanism — what's stored, what goes out, in what order, and what happens when two people changed the same thing.
Where: nothing to turn on — working offline is always on. The Sync screen, in your account settings, shows what hasn't been sent yet.
What you carry with you
Before you even lose signal, the app has already filled your pocket.
Every time you open the app and every time you bring it back to the foreground, Sentinel quietly reloads a local copy of the active place:
- every task in the current activity and their projects;
- the detail page of the tasks in your planning and of each project's tasks;
- the structures and their pages;
- the checklists for the current season;
- the trails, types, folders and the place's reference data.
So it isn't "whatever you looked at recently": it's the whole place, preloaded. You can leave with the phone in airplane mode and open any task on the network.
Two limits, set so your device doesn't fill up:
- at most 200 detail pages from your planning and 30 projects in detail;
- the oldest pages are pruned over time.
Beyond that the list stays readable, but the detail page of a task you never opened may be missing.
Discussions follow a different rule: only the threads you've already opened are cached. A discussion you never looked at isn't readable off the network.
What you see when it cuts out
The confirmation after creating something off the network.
- 1The message says the task is saved and will go out later.
- 2The chip appears for a few seconds when the network is gone.
Two signals, and nothing more:
The "Offline mode" chip appears at the bottom of the screen when the app notices the network is gone, then fades after a few seconds. It comes back if you reopen the app, still offline. It blocks nothing.
A confirmation message appears when you save something without a connection: "Your task has been created and will be synchronized when your internet connection is restored." There's a variant for each gesture — task updated, structure created, report created, time logged.
That's deliberately quiet. Having no network is the normal state in the field, not a failure.
What you can do without a connection
Almost everything that produces work:
| You can | Detail |
|---|---|
| Create a task | Point, segment or to-do, with photos, materials, annotations |
| Edit a task | Any field, including status and assignee |
| Delete a task | The deletion goes into the queue like everything else |
| Log time | The entry is saved with its task |
| Tick a sub-task | And a checklist item |
| Create, edit, delete a structure | And create an inspection report |
| Write in a discussion | The message goes out when the network returns |
| Take photos | They follow their own queue — see below |
What is not possible off the network: anything that needs an answer from the server right then — signing in, switching place, opening a page that was never cached, or administration data.
Every gesture becomes a pending item, written to the phone. That list is what we call the sync queue.
How the queue empties
The Synchronization screen.
- 1The button retries everything pending or failed.
- 2A pending item: its type's icon, and the time of the gesture.
- 3An item needing attention is orange and opens with one tap.
The Synchronization screen, in the account settings, is the source of truth: it lists what hasn't gone out yet.
When it goes out
The queue restarts on its own on four triggers:
- the network comes back;
- you reopen the app;
- you add a new item;
- the system wakes the app in the background — the phone picks the moment, but the queue can empty without you opening anything.
The Sync all button forces an immediate pass. It's greyed out when there's nothing to send, or when there's no network.
In what order
Oldest first. The queue's order is the order of your gestures, which guarantees a task created at 9 am exists before its 11 am edit goes out.
An item that can't be read or is permanently rejected is set aside rather than blocking the queue: one problem never holds up the rest.
When it fails
A failed send isn't lost, it's retried — with a delay that doubles each time: about one second, then two, four, eight… up to a five-minute ceiling. After ten attempts, the item is marked failed and waits for your decision.
That spacing is deliberate. At the edge of coverage, where the network comes and goes, retrying non-stop would drain the battery without sending anything.
Two reminders warn you if it drags:
- after several consecutive failures, a box appears in the app with a Fix button that goes straight to the Synchronization screen;
- reminder notifications are scheduled at 2 h, 4 h, 8 h and 16 h while items remain pending — never between 10 pm and 8 am.
An item's states
| What you see | What it means |
|---|---|
| The type's icon, in grey | Pending — it will go out on the next pass |
| A blue sync icon | Sending |
| An orange icon with two bars | Conflict — someone else touched the same thing |
| An orange icon with an exclamation mark | Failed — the send didn't work |
The last two are tappable: that's where you decide.
Conflicts
This is the part that matters. You were off the network; meanwhile, the person at the office may have touched the same task. Sentinel tells four situations apart.
A similar task already exists nearby
When a task or structure created offline finally goes out, Sentinel first checks whether one of the same type already exists right beside it. That's the classic case: two volunteers report the same fallen tree on the same Saturday.
The item goes into conflict and shows you the candidates. It's up to you to say Create anyway, if it isn't the same problem, or to delete your item if it's a duplicate.
That check only happens on send — it needs the server. Which is why it sometimes shows up hours after the creation.
Someone edited the task while you were away
Resolving an edit conflict.
- 1Only genuinely contested fields are listed.
- 2Your value is kept by default.
This is the most interesting case, because Sentinel settles most of it by itself.
The app doesn't send the whole task back: it sends the fields you changed, and for each one it knows what the value was when you changed it. At send time, three cases per field:
- the server already has the same value as you → nothing to do, move on;
- nobody touched that field → your change is applied, silently;
- someone changed it, differently from you → conflict on that specific field.
In practice: if you changed the status and your colleague changed the description, there is no conflict at all. Both edits land. You're only interrupted for what is genuinely contested.
When a contested field remains, the screen shows My value and Server value side by side, field by field. Yours is kept by default; you flip whichever you want, then Apply. Or Discard changes, and the server's version stands.
The task was deleted
If the task disappeared from the server in the meantime, your edits can no longer apply. The screen tells you, shows what you had changed, and your only option is to discard. That's the one case where offline work is genuinely lost — and it's because its target no longer exists.
You had asked for a deletion
If you deleted a task offline and someone has edited it since, you're asked to confirm: Delete anyway or Cancel deletion.
Photos
Photos have their own queue, separate from the rest. That's on purpose: a photo weighs a hundred times a status change, and a slow upload must not hold up your other gestures.
Three things to know:
They wait for their task. A photo taken on a task created offline can't go out before the task actually exists on the server. The queue handles it: as soon as the task is created, the photos waiting on it are attached automatically.
Three at a time, no more. So a weak connection doesn't get saturated.
A watchdog looks for stalls. An upload that drags on is detected and restarted. If it persists, the app offers: "Media upload stuck — Retry?"
On Android, an upload in progress keeps going even if you leave the app.
The one trap
Don't log out with pending items.
The queue lives on the device, tied to your session. Logging out wipes the local data — and with it everything that hasn't gone out. The app warns you first, with an explicit message, but the warning is easy to swipe past.
The safe rule: before logging out or uninstalling, open the Synchronization screen and check that it says "Everything is synchronized".
The same reasoning applies to a lost or reset phone: what hasn't gone out exists nowhere else.
What about the web?
The web app does not work offline, and that's on purpose: you use it at a desk, on a connection.
It does share the same protection against concurrent edits. If two people change the same task at the same time, the server detects the mismatch and the same logic applies: what nobody else touched goes through, the rest is flagged.
Four pieces of advice
Open the app before you leave, while on the network. Thirty seconds of Wi-Fi in the parking lot and you leave with the whole place in your pocket.
Don't count on pages you never opened. The preload covers the essentials, but it's bounded. If you know you'll be working on a specific project, open it once before leaving.
Check the Synchronization screen when you get back. Thirty seconds, once per outing. It's the only maintenance the offline mode asks of you.
Deal with conflicts the same day. A two-week-old conflict is one nobody remembers — and the right answer becomes impossible to give.