> For the complete documentation index, see [llms.txt](https://docs.amltd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amltd.com/dc-works/core-concepts/offline-operation-and-synchronization.md).

# Offline Operation and Synchronization

DC Works allows enrolled mobile devices to continue collecting data when a network connection is temporarily unavailable.

Information captured offline is stored locally on the device and synchronized with the cloud when connectivity is restored.

```mermaid
flowchart LR
    A["Applet"] --> L["Local Device Cache"]
    L -->|Connection available| C["DC Works Cloud"]
    C --> T["Tables"]
```

### Offline operation

When a device loses its network connection, supported Applet workflows can continue using locally available information.

This is useful in environments such as:

* Warehouses with inconsistent Wi-Fi coverage.
* Outdoor or remote work areas.
* Vehicles and mobile operations.
* Facilities where network access is temporarily interrupted.

Users can continue entering or scanning information without waiting for the connection to return.

### Local data

Information collected while offline is temporarily stored in a local cache on the device.

Depending on the Applet and the data already available locally, users may be able to:

* Enter or scan information.
* Continue through Applet pages.
* Use local records and workflow logic.
* Add information that will later be synchronized.

{% hint style="info" %}
Offline availability depends on the information and functionality required by the Applet. A workflow that requires data not already available on the device may need an active connection.
{% endhint %}

### Synchronization

When a connection is available, DC Works synchronizes data between the device and the cloud in the background, every 2 minutes.

```mermaid
flowchart TD
    O["Data Collected Offline"] --> L["Stored on Device"]
    L --> N{"Connection Available?"}
    N -->|No| L
    N -->|Yes| S["Synchronize"]
    S --> T["Cloud Table Data"]
```

Synchronization allows information collected on mobile devices to become available to other devices and Web Apps working with the same tables.

### Offline records are not immediately shared

Until synchronization occurs, information stored locally on one device may not be available elsewhere.

This means:

* Other devices may not immediately see newly collected information.
* Web App users may not see offline activity until it synchronizes.
* A device should be allowed to reconnect and complete synchronization before locally stored information is considered available throughout the solution.

{% hint style="warning" %}
Do not assume that information collected offline has reached the cloud until the device reconnects and synchronization is completed.
{% endhint %}

### Design workflows for offline use

When offline operation is important, consider:

* Which information must already be available on the device?
* Which tasks can continue without current cloud data?
* Could several devices work with the same information while disconnected?
* How will users know whether data has synchronized?
* Does the workflow depend on immediate validation or lookup?
* What should happen if a connection is unavailable?

Offline behavior should be tested under realistic conditions before the solution is deployed.

### Web Apps and connectivity

Web Apps operate through a supported browser and require network access to communicate with DC Works.

Offline data collection is primarily intended for enrolled mobile devices running the DC Works application.

### The Getting Started example

If the enrolled device loses its connection while using the **Asset Check-In** Applet, check-in information can be held locally until connectivity returns.

After synchronization, the information becomes available in the cloud table and can be accessed by other authorized devices or Web Apps.

### Next

Continue to **Planning an App** to learn how to define a workflow, identify its data requirements, and plan the Applets, pages, records, and tables needed before building.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.amltd.com/dc-works/core-concepts/offline-operation-and-synchronization.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.