Why a mobile project management app loses data
A typical failure looks like this: an engineer at a site without network closes tasks, reschedules deadlines, adds comments — all of this settles in the local change queue on the device.
When the network appears, the project's mobile client sends the accumulated changes, and some edits do not arrive: the server already has a newer version of the record, and what was sent is silently overwritten.
The user sees “saved,” while the task in the shared list still has the old deadline — the loss of edits is discovered a day later, at the planning meeting.
The second half of the problem is duplicates. A repeated send after a timeout creates the task a second time, two assignees and two sets of checklists get linked to it, and effort counters diverge.
If offline synchronization does not mark each change with a unique operation identifier, it becomes impossible to distinguish a genuinely new record from a repeated send, and this has to be sorted out manually.
Version conflicts surface where two people edit the same task from different devices.
Field-by-field merging — status, deadline, assignee — preserves both edits, while “whole-record” merging leaves only the latest one: someone else's work disappears without a trace and without an entry in the history.
Separately, offline work on long shifts breaks down: the queue grows, the device aggressively saves power, and background sending simply does not finish before the app is closed.
The cost of this failure is measurable: deadlines in the system stop matching reality, the manager makes decisions based on an outdated picture, and the team starts a parallel spreadsheet “just in case.” Trust in the system falls faster than the volume of lost data grows, and restoring it is harder than fixing synchronization itself. Let's break down how this is addressed.
What offline synchronization provides: lost edits, downtime, deadlines
Previously, an offline shift looked like this: edits accumulated on the phone, and when going online, some were overwritten — whoever saved last won.
Proper synchronization removes this class of failures entirely: every action goes into a local log with author and time and is sent in the original order. The question “did the edit not arrive, or was it never there?” no longer arises.
Synchronization time is measured not by the fact of connection, but by the delay until the whole team sees other people's changes. Sending is done as a delta — only changed fields — and in the background, so a short network window at the site is enough.
What accumulated during a shift converges within seconds after the channel appears, not at the next app launch.
Crew downtime is the second category of losses: until the work order is confirmed on the server, the assignee either waits or works from memory and then asks again.
A local copy of the confirmed project version and an outgoing edit queue remove the waiting: downtime shifts from hours to minutes.
Re-entering data used to be the norm: the shift was closed on paper and transferred into the system in the evening.
When edits are merged field by field, two edits to the same task — one changes the deadline, the other the assignee — both are preserved, and there is nothing to rewrite.
What to measure after implementation: the share of lost edits, the time from network appearance to data convergence, the number of re-entries, and the number of conflicts that still reach a human.
The last metric is the most honest of all — it shows how many discrepancies the system could not resolve on its own.
Offline synchronization modes: full, partial, event-based
The exchange mode is chosen not based on platform convenience, but based on three inputs: how much data a person needs in the field, how long they are willing to wait on first login, and how stable the communication channel is. Below are three working schemes that we combine in a single project management app.
| Mode | When it fits | What limits it in practice |
|---|---|---|
| Full download | Field work where tasks, deadlines, and links between them are needed in full and immediately | First login is stretched out, local storage takes a noticeable share of the device, every exchange sends extra data |
| Partial synchronization | A person manages 2-3 projects and sees only their area: loading by project, team, or period | Boundaries must be described in advance — what to do with tasks that fall outside the selection, and how to pull in their links |
| Event-based synchronization | After the initial load, individual fields change: statuses, comments, estimates, attachments | Without a base layer, there is nothing to apply an event to; an operation log and an unambiguous conflict resolution rule are needed |
In practice, a pure mode is rare: the base layer is loaded once, then event-based exchange follows, while a partial selection limits the volume for those who work only in their own area.
The key here is record versioning and a rule for edit priority; otherwise changes are lost silently.
Boundaries are chosen for the scenario, not “for the future”: extra data in local storage means synchronization time and conflicts out of nowhere.
Implementation stages: from scenario audit to handover of regulations
The work order is structured so that offline behavior stops being a surprise in production operation.
First we capture what the employee actually does offline, and only then do we design the exchange — otherwise the synchronization scheme becomes overgrown with edge cases that cannot be tested.
-
Scenario audit. We analyze operations performed without connectivity: editing a task, changing status, comments, attachments, time logging. We mark what cannot be postponed — such actions are blocked until the network appears.
-
Synchronization scheme. We define the exchange unit and source of truth, the format of the local change log, and the last agreement marker. This determines how much data is sent when returning online and how quickly a project with hundreds of tasks opens.
-
Exchange setup. We set triggers — network appearance, timer, user action — batch size, and number of retries on interruption. We separately describe what happens if the device is turned off before the upload completes.
-
Conflict resolution. Rules are set by field types: where the latest record is enough, where values are merged, where the decision is given to a human with both versions shown. Edits by two engineers in the same task do not turn into lost data.
-
Testing on real data. We run a copy of the working project: long chains of edits offline, one task from two devices, clock changes, app update over the local database. Every failure is analyzed down to a reproducible case.
-
Handover of regulations. We provide operating rules: how to read the queue state, what to do with a stuck record, how to export the log for analysis. Support receives instructions before launch, not after the first requests.
What we hand over: schemes, synchronization rules, regulations
Project handover is not an archive with source code, but a set of artifacts by which your staff or another team continues work without deciphering someone else's logic. Everything that determines the app's behavior is documented in writing and handed over together with access. Below is exactly what the package includes.
- Data schemas — local storage structure, relationship with server entities, migration order: a new field does not break the app on older versions.
- Access policy — matrix of roles and permissions for read, write, and delete, system behavior when an employee's access is revoked.
- Synchronization rules — what goes to the server and when, how the operation queue behaves offline, what triggers start the exchange.
- Conflict resolution — by which field record versions are compared, whose change has priority, how the user sees the conflict.
- Operating regulations — order of releasing updates, checks, and release approval, areas of responsibility.
- Instructions for employees — scenarios in user language: conflict, return from offline, failure report.
- Support procedure — request levels, response times, responsible parties, transfer of access to the repository and monitoring.
The package remains a working document: it is used to onboard a new developer, pass a security review, and plan product development.
Case study: field work and synchronization of crew tasks
The client is a service company with field crews: installers work at sites where connectivity is available only near the foreman's office. Requests and photo reports went through messengers, and the dispatcher transferred them into Bitrix24 in the evening. By the end of the week, the transfer queue stretched to two days.
What was broken before implementation
Two installers took the same request and did the work twice: edits overwrote each other on save. Photo reports disappeared if the app was closed without network. The dispatcher assigned tasks from memory because he could not see who was already at the site.
| What was measured | Before | After |
|---|---|---|
| Requests with status discrepancy | 1 in 6 | less than 1 in 100 |
| Work order transfer delay | up to 2 days | minutes after connectivity appears |
| Lost photo reports | every week | 0 |
| Data reconciliation at the dispatcher | 3–4 hours per day | about half an hour |
What changed in the mechanics
Crew actions are written to the local database and go to the server as a queue when connectivity appears. Each operation has its own identifier, so a repeated send after an interruption does not create a duplicate.
Conflicts are resolved by the time of the last change: an edit made in a tunnel later is not overwritten by an earlier one.
Disconnection scenarios were run manually: turning off connectivity in the middle of a round, restarting the app, duplicating the send — the data converges. Recurring failures are gone: double assignments, lost photos, manual reconciliation. The dispatcher handles task assignment, not comparing two versions of the list.
How does offline synchronization differ from ordinary caching?
The difference is where the source of truth is located during work. A cache is a copy of data for reading: it speeds up the task list and project cards, but any change goes to the network, and until the response returns, the record is considered unconfirmed.
If connectivity drops, the interface shows data but cannot accept an edit, and the employee sees “saved” that did not actually happen.
Offline mode is structured differently: writing goes to the local database, and operations — creation, renaming, status change, comment, attachment — are put into a queue with an application order.
While the network is unavailable, the device becomes the source of truth for the client, and the app continues to work fully, not in view-only mode.
When connectivity returns, reverse merging starts: the queue is processed in order, operations are applied on the server, and the result returns to the device — already with server versions of records.
The key here is conflict resolution when someone else managed to change the same task on the server: record versions and timestamps are needed so the decision is predictable, rather than “whoever synchronized last wins.”
Substituting one for the other is what causes losses. A cache on top of concurrent work with tasks creates duplicates and “resurrected” cards on repeated sends, loses edits when storage is cleared, and cannot explain to the user what happened to their change.
That is why in a project management app, offline mode is designed separately: with an operation log, merging rules, and explicit synchronization status indication.
Review of technical questions before work starts
Before the start, the client checks three things: what happens to data if an employee does not go online for a week, who will see tasks if a tablet is lost, and how much of the existing app will remain alive.
Below are short answers to each point; non-standard scenarios are reviewed separately, already during estimation.
How long does the app work without network?
The limitation is not the volume of local storage, but conflict resolution. The projects, tasks, and comments available to the user reside entirely on the device, so edits are made offline, and the operation queue is replayed in order when connectivity appears.
If the same item was changed by two people, the later edit wins, and the previous version remains in the task history — text cannot be rewritten or lost.
How well is data protected on the device itself?
The local copy is encrypted, the key is stored in the device's secure module and is not exposed externally; login is via biometrics or a system code.
We build permission checks according to OWASP recommendations for mobile apps: the server remains the source of truth and rechecks access on every synchronization, rather than trusting a decision made on the device.
The device is lost — will data leak outside?
The working copy is wiped remotely: the app destroys both the local storage and the key, after which it is impossible to read the remnants without the server.
The only thing the company risks is edits that did not manage to reach the server; their volume is limited by the window between the last synchronization and the loss. We configure this window according to your regulations.
Will the existing app have to be rewritten from scratch?
We start with an audit: screen map, data layers, amount of reusable code. Most often the interface and business logic are carried over, while storage, synchronization, and conflict resolution are replaced — plus a one-time data migration without downtime. We fix the scope of rework in stages so you can see what you get at each one.
Let's discuss the task and come back with a synchronization plan
To come back with a work estimate rather than general words, in the first conversation we need to understand how your data is structured and how employees work in the field. Answers can be approximate — we will refine the details based on your schemas and server interfaces.
- Which entities are edited offline — tasks, comments, attachments, statuses — and what is critical not to lose when connectivity drops.
- How exchange with the server currently works: full download or incremental, whether there are change markers and stable record identifiers.
- Who conflicts with whom: two engineers on the same task, an edit from a phone and from a web panel, batch updates on the server.
- Which conflict resolution mode is acceptable: last edit wins, field-by-field merging, or manual review.
- Requirements for access and storage: offline login, local database encryption, lifetime of the queue of unsent operations.
- What already exists in the project: mobile client, server side, permission separation, test environment — this determines the scope of work.
- Scope of the initial synchronization: how many records and attachments the device pulls on first login.
In response, we send a stage-by-stage implementation plan: a synchronization scheme with merging rules, the procedure for data preparation and migration, the scope of work on the client and server, acceptance criteria, and timelines. The estimate is based on your scenarios, not on average market numbers.