How do offline sales apps sync orders to ERP without losing a line?
Reps write orders at fairs, in showrooms and in shops with poor connectivity. How offline-first sales apps store, queue and sync order data to ERP safely, and where it goes wrong.
KEY TAKEAWAYS Summary by the editors
- An offline-first sales app treats the local database on the device as the source of truth and syncs changes to the server when a connection is available.
- Order lines are lost or duplicated mainly when retries are not idempotent, when two devices edit the same order, or when product master data on the device is out of date.
- Idempotency keys let a server recognise a retried request and return the original result instead of creating a second order.
- Every size and colour variant needs its own GTIN, so an offline order must reference variant identifiers that still exist in ERP when the order arrives.
- A reliable setup confirms each order back to the rep, with a clear status per order (saved on device, sent, accepted by ERP, rejected), instead of a single sync icon.
An offline-first sales app saves every order on the device first and sends it to the server, and on to ERP, when the connection returns. Lines are not lost if each order has a unique identifier, retries are idempotent, conflicts between devices are resolved by clear rules, and the app shows the rep whether each order has really reached ERP. Most lost or duplicated orders trace back to one of those four points.
Why do fashion sales apps need to work offline?
Wholesale orders are written in places with unreliable connectivity: trade fair halls, basement showrooms, agents' cars and independent stores. A rep who cannot browse the collection or save an order because the network drops will go back to paper or spreadsheets, and those orders must then be typed into ERP by hand. Salesforce's 2026 State of Sales survey of 4,050 sales professionals found that sellers spend only 40 percent of their time actually selling, with manual data entry among the tasks taking up the rest.
How does offline-first architecture work?
Android's developer guidance on offline-first apps describes the core pattern: the local data source is the canonical source of truth, the user interface reads only from it, and writes go to the local database first and are synced to the network later. For critical data, the guide recommends this so-called lazy write approach, combined with a persistent work queue that retries with exponential backoff when connectivity returns. The same principles apply on iOS and in web apps that store data in the browser.
| Data | Direction | Sync pattern | Risk if stale |
|---|---|---|---|
| Collection, styles, variants, GTINs | Server to device | Full download before the season, then changes | Orders for dropped colours or wrong sizes |
| Price lists per market and account | Server to device | Refresh at login and on change | Wrong prices on order confirmations |
| Images and 3D renders | Server to device | Background download on Wi-Fi | Missing images in front of buyers |
| Accounts, addresses, credit status | Server to device | Refresh daily | Orders for blocked accounts |
| Stock or available-to-sell for in-season | Server to device | Refresh when online, show timestamp | Promising stock that is gone |
| Orders and order changes | Device to server | Queued writes with idempotency | Lost or duplicated orders |
For a fashion sales app, the hardest part is often the volume of data that must be on the device before the rep leaves the office: a full collection with every colour, size, price list and image can be large. Apps usually download the collection in the background over Wi-Fi before the selling season and then fetch only changes. Reps should be able to see, before a fair or a trip, whether their device has the complete and current collection.
Why do order lines get lost or duplicated?
- Retries without idempotency: the device sends an order, the connection drops before the response arrives, and the app sends it again. Without protection the server creates two orders.
- Partial sync: the order header arrives but some lines fail validation, and the app marks the whole order as sent.
- Stale master data: the rep orders a colour or size that was dropped after the device last synced, so ERP rejects the line.
- Concurrent edits: two people change the same order offline, and a simple last-write-wins rule silently overwrites one of the changes.
- Silent failures: the app shows a generic sync icon and the rep never learns that one order was rejected.
What is an idempotency key, and why does it matter for orders?
An idempotency key is a unique value the client sends with a request so that the server can recognise retries of the same request. Stripe's API documentation explains the principle clearly: the server saves the result of the first request for a given key, and later requests with the same key return the same result instead of performing the operation again. Stripe suggests random V4 UUIDs as keys. For a sales app, the device should generate the order identifier and idempotency key when the order is created, not when it is sent, so every retry carries the same key.
How should conflicts and rejections be handled?
Android's guidance describes last-write-wins with timestamps as a simple conflict strategy, but it is risky for orders, where one rep's quantity change can overwrite another's. Many brands therefore lock an order to one editor, or merge at line level and flag conflicts for review. Rejections need equal care. GS1 guidance is that every size and colour variant needs its own GTIN, so a line referencing a withdrawn variant must come back to the rep with a reason, not disappear.
- Generate order ID and idempotency key on the device at creation.
- Validate against local master data before saving, and show the data timestamp.
- Send the order as one unit and require a line-by-line acknowledgement.
- Map server and ERP results back to each line: accepted, changed, rejected with reason.
- Show order status per order on the device and alert the rep to rejections.
- Keep orders on the device until ERP has accepted them, and log every sync attempt.
What should IT test before the selling season?
Test with real devices in airplane mode and on weak networks: create orders offline, kill the app mid-sync, change master data on the server while devices are offline, and edit the same order on two devices. Check ERP for duplicates and missing lines after each test. Salesforce's survey found that 51 percent of sales leaders say disconnected systems hamper their AI initiatives, and the same disconnection causes order errors long before AI is involved.
Agree with the business who monitors sync failures during selling peaks. A rejected order is only harmless if someone notices it the same day, contacts the rep and corrects it with the buyer. A daily report of orders saved on devices but not yet accepted by ERP is a simple and effective safeguard during fairs and showroom weeks.
Frequently asked questions
What does offline-first mean in a sales app?
It means the app stores collection data and orders in a local database on the device and works fully without a connection. Changes are synced to the server, and on to ERP, in the background when connectivity returns.
How do you prevent duplicate orders when a sales app retries?
Use idempotency: the device creates a unique order ID and idempotency key when the order is written, and the server returns the original result for any repeated request with the same key instead of creating a second order.
What happens if a product changes while the rep is offline?
The order may reference a dropped colour, size or price. A good app shows how fresh its master data is, validates again on sync, and returns any rejected line to the rep with a reason so it can be corrected with the buyer.
Should orders go directly from the sales app into ERP?
Usually through an integration or order management layer that validates, enriches and queues orders before ERP. This layer also returns line-level status to the app, which is essential for the rep to know whether each order was accepted.
One edition every weekday morning. Read in five minutes. Free for industry professionals.
