Offline Behaviour and Synchronisation

How the Daxium-Air mobile app handles data when offline and syncs when connectivity is restored.

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.

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.

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.