Offline in SAP MDK: why it breaks in the field

In MDK the device works against a local database synchronised over OData. Everything the app must show or validate without coverage has to be decided in the data model, not patched afterwards. Postpone that decision and the redesign lands during user testing — the most expensive moment there is.

The temptation is to replicate the whole master. The result is a twenty-minute first sync and a phone out of storage. The rule is simple: download what the technician needs for the shift, and nothing else.

• Filter by plant, work centre or crew — never by company code
• Time window on orders and notifications, not full history
• Catalogues and materials scoped to the real work area
• Attachments on demand, never in the initial sync

The delta —what changes between syncs— defines the daily experience. A poorly defined model forces full entity reloads and turns a few seconds into minutes with the app locked.

• Define keys and deltas per entity from the first design
• Avoid unchanged entities that reload anyway
• Measure sync with production volumes, not demo data
• Sync in the background and never block the interface

Two technicians touch the same order. Or the planner reassigns it while one of them is offline. With no agreed policy, the last sync wins and somebody loses their work — usually silently.

• Decide per entity who wins: field, backend or manual review
• Logical lock on an assigned order while it sits on a device
• An error queue the technician can see, not just a log entry
• Never discard a failed record without telling anyone

Offline always works in the lab. The useful tests are the uncomfortable ones: airplane mode for hours, patchy coverage on the drive, battery at ten percent, the OS killing the app mid-sync, and a full shift without logging out.