Working with no signal
When the crew app has no signal it keeps working: timers, item completions and notes are stored on the device with the time they actually happened and sent automatically the moment the connection returns.
On most of the water where dock work happens the bars go at the first narrows and come back on the way home. LakeOps treats that as the normal condition rather than an error state.
The idea underneath it
The device is where work is recorded. The network is an occasional opportunity to tell the office about it. Everything else follows from taking that literally.
So there is no “save” that can fail. A tap is written to the phone with the time it happened, and the phone sends it when it can. The crew sees a count of what is still waiting; they do not have to do anything about it.
What survives a dead zone
| Works offline | Waits for signal |
|---|---|
| Reading the whole day from the day pack | Photo uploads |
| Starting and stopping the clock | Map imagery for water the device has not seen |
| Marking items done and skipping them | Anything on the office screens |
| Writing notes and correcting a pin |
A resend is never a double
A boat coming back into range flushes everything it has been holding, and a marginal connection may flush some of it twice. Every queued action carries a key minted on the device at the moment of the tap, so the second arrival is recognized and ignored. One tap, one timer, one completion, one customer email — however many times it is sent.
Order is the order the work happened
The device stores actions by key, not by time, so a batch can easily arrive with a timer stop ahead of its start. The server sorts by when the work actually happened before replaying, and a stop that still arrives before its start is held and retried rather than dropped.
Who wins when two people did different things
The office marks a job complete at the desk while a crew member marks an item done on the water. Both are legitimate. The rules are decided in advance and they are short:
- The server never un-completes work. A completion, once recorded, stands.
- An office edit beats a field edit on the same field.
- Between two device edits, the later one wins.
- Device clocks are clamped to a fifteen-minute skew, because phones lie about the time.
One write path, and why it matters to you
A completion replayed off a boat’s queue runs through exactly the same code as a completion clicked in the office. There is no separate “sync handler” that could drift out of step. If they were different code the differences would surface in the field, months later, in an argument about a bill.
Permissions still apply
Every queued action is checked against the person’s role when it lands, not just when the button was drawn. Someone whose role cannot run timers cannot get a timer in through the back door by being offline.
What to actually tell a crew
- Pull the day pack before you leave.
- Work normally. Do not wait for bars and do not batch it up at the end of the day.
- Photos may sit until you are back in range. That is expected.
- Do not force-quit the app to “make it sync”. It sends on its own.
The reasoning behind all of this is on the crew app page.
Still stuck? Ask us — or go back to the help center.