[Developers]

Offline Operations Domain

Field investigators entering a tunnel network, remote border post, or disaster-affected area cannot pause their work until they find a signal. The Offline domain queues every data modification made while the device is di

Category: Api DomainsLast Updated: Feb 5, 2026
api-domains

Overview#

Field investigators entering a tunnel network, remote border post, or disaster-affected area cannot pause their work until they find a signal. The Offline domain queues every data modification made while the device is disconnected, preserves the correct operation order, and synchronises everything automatically the moment connectivity returns. When field-collected data conflicts with server-side changes, configurable resolution strategies handle the discrepancy without manual intervention in most cases.

Key Features#

  • Mutation Queuing: Captures and stores all data modifications locally when the device is offline, preserving operation order and context
  • Batch Synchronisation: Automatically synchronises all pending operations when network connectivity is restored, processing them in the correct sequence
  • Conflict Resolution Strategies: Supports server-wins, client-wins, merge, and manual resolution for concurrent modifications
  • Operation Tracking: Tracks each queued operation by type, domain, entity, and device for complete visibility into pending changes
  • Automatic Retry Logic: Failed synchronisation attempts are automatically retried to handle transient network issues
  • Real-Time Sync Status: Each operation is tracked through its lifecycle: pending, synced, failed, and conflict
  • Per-Device Queue Management: Manages separate operation queues for each device, supporting multi-device field operations by the same user
  • Ordered Processing: Maintains operation sequence integrity during synchronisation to ensure data consistency

Use Cases#

Relevant sectors include law enforcement, defence, and critical infrastructure field operations.

  • Field investigators capture evidence observations and case updates on mobile devices in areas with limited connectivity, with all changes automatically syncing when they return to network coverage.
  • Rural operations teams working in areas without reliable cellular service queue investigation updates throughout the day, with batch synchronisation handling all pending changes when connectivity is available.
  • When field-collected data conflicts with updates made by other team members on the server, the conflict resolution system identifies discrepancies and applies the configured resolution strategy, or flags them for manual review.
  • Multi-device operations are supported where an investigator may use different devices in the field, with per-device queue management ensuring all changes from all devices are properly synchronised.

Integration#

The Offline domain integrates with the offline map tile system for map access without connectivity, the synchronisation coordinator for managing sync workflows, the device management system for device tracking, and the investigation system for field-based case operations.

Open Standards#

  • GraphQL: All offline mutation operations, sync status queries, and conflict resolution inputs are exposed through a typed GraphQL API, with enums and input types defined per the GraphQL specification.
  • JSON (RFC 8259 / ECMA-404): Mutation payloads, entity versions submitted for conflict resolution, and metadata fields are all stored and transmitted as JSON, persisted server-side as JSONB.
  • RFC 4122 (UUID v4): Every queued mutation and every conflict resolution record is assigned a universally unique identifier generated as a version-4 UUID, ensuring collision-free identity across distributed field devices.
  • ISO 8601 / RFC 3339: All timestamps, including created_at, synced_at, and resolved_at, are represented as UTC datetime values conforming to the ISO 8601 profile used in internet protocols.
  • OAuth 2.0 (RFC 6749): Write access to the mutation queue is gated by an RBAC permission check that operates within the platform's OAuth 2.0 authorisation framework, requiring a valid access token scoped to the target domain and entity.
  • Operational Transformation (OT) conflict model: The four-strategy conflict resolution model (last-write-wins, first-write-wins, deep merge, manual review) follows the conventions established in the operational transformation and CRDT literature for distributed offline-first systems, providing deterministic convergence when concurrent edits are replayed on reconnection.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Ready to Build?

Get started with our APIs or contact our integration team for support.