# Offline Behaviour and Synchronisation
The Daxium-Air mobile apps are built to work **offline first**. Your teams can keep collecting data in the field with no network — in a basement, a remote site, or on a plane — and the app takes care of synchronizing everything once a connection is back.
## Working offline
Everything your users need is stored locally on the device: the forms, the lists and lookups, and the data entries themselves. With no connection, users can:
* create new submissions,
* edit existing submissions,
* save drafts,
* add photos, signatures, and attachments.
Nothing is lost while offline. Work stays safely on the device until it is either sent to the server or deleted. Synchronization is what later pushes your changes up to the server and pulls the latest data down.
## What synchronization does
Synchronization works in two directions:
* **Download (server → device):** forms, lists, permissions, and the submissions that concern the user (assigned to them or broadcast to their team).
* **Upload (device → server):** submissions created or edited while offline, along with their photos and attachments and comments.
### Required vs. background steps
Not all synchronization steps carry the same weight. Some are **required before the app is usable**; others run in background.
**Required steps, completed before you can start working.** The app stays on the synchronization screen until these finish:
| # | Step | What it does |
| - | ------------------------------ | -------------------------------------------------- |
| 1 | *Fetching forms* | Downloads your forms. |
| 2 | *Fetching account information* | Retrieves your account configuration and settings. |
| 3 | *Fetching form dependencies* | Loads everything the forms rely on. |
| 4 | *Fetching lists* | Downloads lists and lookup values. |
| 5 | *Fetching automatisms* | Loads automation rules. |
**Background steps, run while you are already using the app.** Once the required steps are done, the app opens and the others continue in background. A failure here does not block you and retries on the next synchronization:
| # | Step | What it does |
| -- | ---------------------------------- | -------------------------------------------------------------------------------------- |
| 6 | *Sending pending submissions* | Uploads submissions created or edited offline (photos and attachments are sent first). |
| 7 | *Fetching assigned submissions* | Downloads submissions assigned to you. |
| 8 | *Fetching broadcasted submissions* | Downloads submissions shared with your team. |
| 9 | *Fetching tasks* | Downloads your tasks. |
| 10 | *Fetching related submissions* | Downloads linked submissions referenced by your forms. |
| 11 | *Fetching comments* | Downloads comments attached to submissions. |
| 12 | *Fetching resources* | Downloads media and map resources. |
| 13 | *Updating synchronization data* | Finalizes the sync and records the new synchronization date. |
{% hint style="info" %}
If a required step fails, the sync stops and an error is shown. Background steps are best-effort: a failure is logged and retried later, without blocking the app.
{% endhint %}
## When does the app synchronize?
**Automatically:**
* At login, if the app has just been updated, has never synchronized before, or if the last sync is more than about a day old.
* When the connection comes back, if submissions were waiting to be sent.
**Manually:**
* Users can trigger a synchronization on demand at any time (sync action in the app) if the configuration allows it.
The date of the last synchronization is shown in the app settings. Sync progress is displayed on screen while it runs, and a running synchronization can be cancelled, it will resume on the next sync.
## Submission statuses
Every submission carries a status that tells you where it stands between the device and the server:
| Status | What it means | Editable? | Sent to server? |
| -------------------------- | ----------------------------------------------- | ------------------------------ | ------------------- |
| **Draft** | Created or edited locally, not yet finalized | Yes | No |
| **Pending** | Finalized and queued, waiting to be sent | Yes, until sent | Not yet |
| **Updated** | Already on the server, then edited locally | Yes | Not yet |
| **Error** | The server refused the upload | Yes — can be fixed and retried | Attempted, rejected |
| **Synchronized** | Sent to the server and confirmed | Yes | Yes |
| **Remote / search result** | Exists only on the server, not modified locally | No — read-only | Yes |
The normal lifecycle of an offline submission is: **Draft → Pending → Synchronized**. The **Error** status is the one to watch — it means something needs the user's attention before the submission can be sent.
## Conflict rules
A conflict happens when the same submission changes in at least two places, for example offline on a device, and on the server, before the device has had a chance to sync.
### Offline work is protected during downloads
Routine downloads never overwrite a submission you have changed locally. As long as your submission is a `Draft`, `Updated`, `Pending`, or in `Error`, your local version is kept and the incoming server version is set aside. Your work is always kept, background syncs cannot silently erase what a user is editing.
### Rule : last write wins
There is no conflict management when a submission is sent, the last sent overrides existing data, but all previous versions are saved on the server.
### Deletions
* Deleting a **local draft** removes it on the device only, nothing is sent.
* A submission **deleted on the server** disappears from the user's lists on the next synchronization if it is assigned or broadcast. If it came from the search, it is not sendable to the server and should be manually deleted.
## Other rules
**Media before the form.** Photos, signatures, and attachments are uploaded before the submission they belong to. If a file fails to send, the whole submission stays `Pending` and the app retries later. This guarantees a submission is never stored on the server with missing attachments.
**Linked submissions (parent / child).** A child submission cannot be sent before its parent, so links between submissions are never broken. Depending on how the relation is configured, children may have to wait for their parent to be sent first.
## For administrators
A few back-office configuration choices directly influence what users experience during synchronization:
* **Form design and validation.** Required fields and validation rules are enforced by the server. A submission that doesn't satisfy them will be rejected on upload and flagged in `Error`, so well-designed forms reduce sync errors for field teams.
* **Relations between forms.** Relation settings affect the send order of linked submissions (parents before children) and whether children wait for their parent.
* **Lists and lookups.** These must be downloaded before the corresponding forms can be filled — large lists add to the initial sync time.
## FAQ
Will I lose my work if I'm offline?
No. Everything you create or edit offline is kept safely on the device until it is sent to the server or you delete it yourself.
Why did my submission end up in "Error"?
Most often because the server refused it — either a validation rule wasn't met, or the same submission was changed on the server while you were editing it offline. Open the submission, check it against the latest data, and send it again.
How long does synchronization take?
It depends on the volume of forms, lists, and media, and on the quality of the connection. The required steps run first; everything else continues in the background without blocking the app.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://www.center.daxium-air.com/user-documentation/support/admin-support/offline-sync.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.