Proving an offline-first field app across Android and Windows

Field continuity

One product model, tested in the places field work actually happens.

The proof was not a screen tour. It was a working slice: sign in, read assigned work, lose connectivity, keep going, then return online without changing the screen contract.

01

Identity

02

Offline read

03

Two targets

Screens keep reading local data. Sync becomes a background behaviour, not a prerequisite.

Field service does not happen at a desk

Hardy Mechanical technicians work wherever the equipment is: commercial buildings, active construction sites, mechanical rooms, and basements. Those environments make reliable connectivity an unsafe assumption.

Kwixand Solutions Inc., a Microsoft Partner, had already built Hardy's original field workflow in Power Apps. The proof of concept explored whether a React-based application could give technicians secure access to assigned projects, documents, and dispatch information across Android and Windows without making connectivity a prerequisite.

Reducing the platform vision

The goal was not to reproduce Hardy's entire operational system. The proposed platform could eventually include technician workflows, expense validation, management approval, dispatch, documents, photos, signatures, and internal tools. Building all of that would have produced a larger demo without necessarily answering the hardest questions.

I reduced the proof of concept to four assumptions:

• Can a technician authenticate through Microsoft Entra ID?
• Can assigned work come from Business Central through a controlled application boundary?
• Can previously synchronized information remain available without a network connection?
• Can the same product be delivered credibly across Android and Windows?

I defined the reduced proof-of-concept scope, designed the offline data model and synchronization approach, implemented the authentication and data-access flows, built the assigned-work interface, and prepared the application for its target device paths.

The application boundary did two jobs: technicians signed in through Microsoft Entra ID, while Business Central records were mapped into field-facing job contracts before the interface rendered them. The device did not need direct ownership of enterprise credentials to make the workflow useful.

Designing one field workflow

The first product experience stayed narrow: sign in, see assigned jobs and dispatch information, open a job, review the details needed in the field, keep reading when connectivity disappeared, and return online without restarting the experience.

That was enough to test the foundation without confusing feasibility with a finished product.

The same job contract supports a wider list-and-detail workspace without becoming a separate product.

Assigned work

The field view stays focused on the technician.

Schedule

The same work model supports a wider operating view.

Detail

Documents stay with the job context.

The same product model supported a phone in the field and a wider Windows workspace. Shared code covered product logic, data mapping, state handling, theme tokens, and most of the interface structure; platform-specific seams stayed available where the devices needed to behave differently.

Building around unreliable connectivity

Offline access could not be an error screen or a later enhancement. Connectivity had to be treated as application state that could change at any point during a technician's work.

The app reads screens from local data. When network access is available, sync refreshes the local snapshot from Business Central. When connectivity is unavailable, the app continues showing previously synchronized assigned work and uses a small banner to explain the state.

Offline behaviour

The useful proof was that the screen kept working after the network stopped helping.

The proof of concept treated connectivity as changing application state. Assigned work synchronized while online, then remained available from the local snapshot when signal was unavailable.

Cache state

Readable offline

The interface keeps reading from the local snapshot while sync waits for the network to return.

01

Online

Load assigned work

The technician signs in and synchronizes assigned jobs into a local read model.

02

Offline

Lose the signal

The connection state changes, but the list does not disappear or become an error screen.

03

Local

Keep reading locally

The current job remains readable from the same cached contract used by the online screen.

04

Refresh

Refresh when possible

When the network returns, sync refreshes the snapshot without changing the screen model.

Local job snapshot

Assigned jobs, schedule details, customer context, address, service type, status, and sync metadata.

Kept out of local storage

Service credentials, client secrets, production token material, and long-term document storage.

Offline writes were deliberately left outside the proof of concept. Conflict rules, retry queues, document lifecycle, retention policy, and support diagnostics needed production decisions before being presented as solved.

For the proof of concept, the local store held approved read-model data and sync metadata. It did not store Business Central service credentials, client secrets, token material, or anything that should require secure storage.

What the prototype established

The proof of concept gave Kwixand a working reference for the Hardy direction. It changed the conversation from "Should this be possible?" to "Which workflows should be added after the foundation?"

The prototype proved the delivery model and offline read workflow. Production hardening, offline write conflicts, device management, document lifecycle, and broader Business Central integration remained outside its scope.

That boundary was the point. The work replaced several expensive assumptions with tested architectural decisions, starting with the places technicians actually work.