Designing an Offline-First ITSM Client for Unreliable Networks

Connectivity is not a detail when a service desk supports people working across different devices and locations. If a technician can open a ticket only while the network is healthy, the application has moved an infrastructure problem directly into the user's workflow.

Start with the operation, not the screen

The important design question is not whether a page can be cached. It is whether an operation can be completed safely and understood later. In an ITSM client, that means ticket creation, status changes, and comments need durable local intent.

I separate the client into four layers:

• screens capture intent and display state;
• providers coordinate feature state;
• services own API and offline fallback behaviour;
• network and storage modules handle tokens, connectivity, cache, and the write queue.

That boundary keeps retry logic out of widgets and makes each domain easier to test.

Queue writes with enough context to replay them

An offline queue should store more than an endpoint name. A useful record includes the operation type, local identifier, payload, creation time, retry count, and any dependency on an earlier queued action. For example, a comment created against a new offline ticket cannot synchronise before the ticket receives its server identifier.

The interface should acknowledge the local result immediately, label it as pending, and preserve it across restarts. Silent failure is worse than a visible offline state.

Reconnect does not mean the API is ready

A device can have a network route while the backend is unreachable. Synchronisation therefore needs a real service check, bounded retries, and clear failure categories. Authentication errors, validation failures, and transient network failures should not all return to the queue in the same way.

Resolve conflicts as a product decision

When local and remote state changed independently, "last write wins" is not automatically correct. Ticket status may require server-enforced transition rules, while a draft comment may be safe to append. The conflict policy belongs to the domain, not to a generic synchronisation helper.

Make the queue observable

Users need to see what is saved locally, what is synchronising, and what needs attention. Engineers need structured logs around queue depth, retry outcomes, and reconciliation latency. Offline-first reliability is achieved when both the user experience and the operating model explain the same state.

The result is not merely an application that opens without a network. It is a system that protects work until the backend can accept it safely.