Azumuta supports offline work primarily for shop floor execution in the Azumuta app. This lets operators keep working when connectivity is unstable or unavailable; their data is synchronized once the device reconnects.
Offline support is strongest for execution workflows such as work instructions, product order execution, and audits. It is less suited to administrative tasks, live collaboration, or other back-office workflows.
Offline availability is configured per device on the device's Offline tab (which content types to cache and the date range to cache them for). See Device Settings: Offline for how to set that up.
Offline Support by Module
| Module | Offline availability | What works offline | Main limitations |
|---|---|---|---|
| Work Instructions | Supported | Pre-downloaded instructions can be opened and executed offline; related assets such as images and media are available if downloaded in advance | Content must be downloaded beforehand; operators continue on the version stored on the device until the next sync |
| Product Orders | Supported (beta) | Operators can continue product-related execution and register progress offline when the required data is already on the device | Beta feature, may still evolve. Changes made elsewhere while offline aren't deeply conflict-managed, since there's no communication with the device. Starting or finishing an order still requires connectivity |
| Audits | Supported | Operators can continue capturing audit execution and evidence offline | Same dependency on preloaded data as product orders |
| Trainings | Partially supported | Cached training-related execution context can be available offline in supported operator scenarios | Uses passive caching rather than the active pre-download used for the other modules; offline support is more limited than for work instructions, and broader administrative training management isn't part of the main offline scope |
Module-specific details:
How Recordings Behave
In all supported offline execution scenarios, recordings follow the same pattern:
- The operator starts or continues work.
- The recording is stored locally on the device.
- The recording is queued while the device is offline.
- The recording is synchronized automatically once connectivity returns.
This means operators can keep working without losing progress, as long as the relevant content was already available on the device.
Recording Behavior by Scenario
| Scenario | What happens |
|---|---|
| Device is online | The recording is sent directly to the platform during normal operation |
| Device goes offline during execution | The recording continues locally and is stored on the device |
| Device starts offline, with content already downloaded | The operator can still execute the flow; the recording is created locally and queued |
| Device starts offline, without required content downloaded | The flow may not be available, so execution may not be possible |
| Device reconnects later | Queued recordings are synchronized automatically |
| A new work instruction revision is published while offline | The operator continues on the version already on the device; the recording remains linked to that version |
| The same underlying record is changed elsewhere while offline | The local recording still syncs later, but advanced conflict resolution is limited |
Important Boundaries
- Offline support is focused on doing the work, not full offline platform administration.
- Pre-downloaded content is key to a successful offline experience.
- The strongest support is in the operator experience.
- Browser-based offline admin support is available, but limited.
- If data changes elsewhere while a device is offline, Azumuta prioritizes continuity and later synchronization.
In Short
Azumuta already provides solid offline support for core operator execution flows. Operators can keep working offline in supported scenarios, and recordings are stored locally first, then synchronized automatically once the device is back online.