In every Business Central integration demo, a technician scans something, the record appears in the ERP, and the room nods. Then the pilot goes live. Within six weeks the same asset exists three times in the system, a work order exists in the app but not in the ledger, and the stock figure has quietly stopped being trusted by the people who have to order against it.
None of that is a coding failure. It is a design failure – of keys, timing, units and ownership. And it is predictable, which means it can be prevented before the first record is written.
Why field-to-ERP integrations fail differently
An office integration connects two systems that both have an operator sitting in front of a screen. A field integration adds a third party: reality. The technician is wearing gloves, standing in the rain, working against a service window, and the machine or vehicle in front of them does not match the record in the ERP.
Three asymmetries follow from that, and every failure in this article is a version of one of them.
Latency
The ERP is minutes or hours behind the workshop. Someone will decide on stale data. The only question is whether the system tells them it is stale.
Identity
The field creates records the ERP never planned for: a component fitted from another unit, an asset that exists physically but not yet digitally.
Authority
Two systems can edit the same field. Without an explicit rule, the last write wins, and the last write usually has the least context.
This is why integrations that pass user acceptance testing still fail in month three. The test data was clean, complete and created by the project team. Production data is none of those things.
None of this depends on the asset being a truck. The same six failures appear with pumps, transformers, serialized tooling, medical devices in the field, and any machine whose service history has to survive being moved, repaired and replaced. Fleet work is the running example here because the pattern is easiest to see in it. The mechanics are identical everywhere else.
Four ways to integrate Business Central, and what each one really costs
Before the failure modes, the pipe. There are four approaches to a Business Central integration, and they are not interchangeable. The choice determines which failures you will spend the next two years fixing.
| Approach | Best for | What breaks first | Who owns it after go-live |
|---|---|---|---|
| REST API / web services OData, SOAP, custom endpoints |
Standard entities, high volume, a custom app you control | Throttling, paging, and schema changes on a version upgrade | Your development team |
| Built-in connectors Dataverse, Sales, Field Service, Shopify, Fabric |
Microsoft-to-Microsoft, standard objects | Field-mapping assumptions, and the custom fields it will not carry | Microsoft, plus whoever configured it |
| iPaaS Power Automate, Logic Apps, Boomi, Workato |
Many SaaS endpoints, low-code teams, a fast first version | Run history nobody reads, per-run cost at volume, no transaction boundary | Whoever built the flow – often a contractor |
| Custom middleware | Non-standard rules, offline reconciliation, high volume | It becomes a product you have to maintain | You |
The same four options the Microsoft reference lists, scored on what they cost you after go-live rather than what they promise at kickoff.
Most failed projects chose the third row because it demoed fastest. Most durable ones use the first or fourth row for the asset-critical path, and the third row for everything around it: notifications, document sync, reporting feeds. The split matters, because an iPaaS flow has no concept of a transaction that spans five writes.
Six failures that only appear after go-live
Each one is invisible in a demo, and each one is cheap to prevent if it is designed for before the first record exists.
No natural key, so the same asset exists three times
The field app creates an asset because the identifier was typed slightly differently. The ERP already had it, from an earlier import, under a different number. Now there are three records, and a year of service history split across them. It happens with vehicles, pumps, compressors and serialized tools alike. The object does not matter; the duplicate does.
Internal IDs from either system are a poor anchor. A Business Central integration needs a key that survives both sides: a registration, an asset tag, or a serial that is physically on the object. If the object has a serial, use it, and make the field app refuse to create a second record for a serial that already exists.
The offline window nobody designed for
Field work has dead spots: basements, plant rooms, hangars, the far end of a yard, a site with no signal. The app queues the record locally, which is correct, but the integration was designed for a real-time call-out, not a batch arriving ninety minutes later with timestamps out of order.
Design the queue before the screen. Decide the maximum offline duration you will support, whether the record may be edited twice before it syncs, and what happens when the same object was changed in the ERP in the meantime. “It will sync when it reconnects” is not a design.
Units, rounding, and the 0.4 millimeters that fails an audit
The gauge returns 7.35 millimeters. The app shows one decimal. The ERP field accepts two. Finance reports in fractions of an inch because one depot still does. Nobody notices until a warranty claim is rejected on the exact measurement.
Every quantity in the integration needs one canonical unit and one rounding rule, defined once and applied at the boundary. This is the cheapest failure to prevent and the most embarrassing to explain.
Historical data that predates the integration
The integration goes live in June. The asset has eleven years of service history in spreadsheets, in the previous system, and in a filing cabinet. The new system reports that this component has no history, and every algorithm, report and dashboard built on that history is now wrong.
Decide explicitly whether history is migrated, referenced or written off. If it is migrated, decide what a migrated record means: it has no technician, no verified timestamp and a different granularity. Labeling it honestly is better than blending it with clean data.
Silent sync failures
A record fails validation at 02:40. The queue retries, fails again, and stops. Nothing is logged anywhere the operations team looks, so the only signal is a technician saying, three weeks later, that the app “sometimes doesn’t save”.
Every integration needs a dead-letter queue, an alert that reaches a named person, and a replay button. The measure that matters is not uptime. It is the age of the oldest unsynced record. Put that number on a dashboard and it will prevent more incidents than any amount of code review.
Two systems, two owners of the truth
The ERP says the component is at position two. The app says position three, because it was moved on Saturday and the move was never approved. A tire rotated to another axle, a pump moved to a different skid: both are right in their own context, and the integration has no rule for who wins.
Write the authority matrix before the first line of code: which system creates the record, which may modify which fields, and what happens on conflict. Usually the answer is that the ERP owns financial and contractual fields, the field app owns condition and location, and anything else is a workflow, not a sync.
The measure that matters is not uptime. It is the age of the oldest unsynced record.
What a working integration contract looks like
None of the failures above are exotic. They are all preventable with seven clauses that cost a day to design and a quarter to retrofit.
An integration without these is not finished. It is a prototype that happens to be in production.
Designing the field screen so the data stays clean
Most data quality problems in field-to-ERP projects are user interface problems wearing a data costume. A technician under time pressure will take the shortest path through any screen, and the shortest path is usually the one that produces a plausible wrong value.
Position is a pick, not a text field
A position typed by hand will eventually be typed as “2” and “02” and “left rear”.
Constrain the choice set
Only what exists in the ERP at that moment, cached so it survives the offline window.
Show the previous reading
A 40% jump is usually a mistake, and the person holding the gauge is the only one who can catch it.
One photo, where it will be argued about
A measurement, a defect, a damage claim. One image settles a conversation that documentation never does.
Block impossible state transitions
In the app, where the person can still fix it, not in the ERP three hours later.
An app that lets someone type a serial number will produce transcription errors at a rate no validation rule can fix. Ask for the serial, scan it, or confirm a match from a short list.
How we scope a Business Central integration
Five questions decide most of the architecture, and they are worth answering before anyone opens a license.
What is the asset, and what is its natural key?
If the answer is “the ERP’s internal ID”, the field side will create duplicates.
Which system is allowed to create it?
One creates, the other references. Decide which before the first record exists.
What must work offline, and for how long?
This single answer determines whether you need a queue, a conflict model, or both.
What is the acceptable lag?
If someone will act on that data within ten minutes, batch sync is the wrong design.
Who is called at 02:00 when a record fails?
If the answer is nobody, the integration is not operational yet.
We run this as a short discovery before quoting, because the answers change the scope by a factor of three. You can read more about how we build custom software and system integrations, or see what the answers looked like on a live project below.
What this looked like in production
Three deployments, three different industries: fleet servicing, aviation ERP and airport ground operations. The failure patterns repeated in all three.
Case study 01
35,000 tires, one record each
A logistics servicing company tracked tires across a commercial fleet with spreadsheets and paper. A field app now reads tread depth and pressure from Bluetooth sensors, attaches every measurement to a serial number, vehicle and axle position, and writes it into Microsoft Dynamics 365. Identity, offline windows and units all appeared in this project.
Case study 02
A live aviation ERP, refactored without stopping operations
An aviation platform running on Microsoft Business Central needed six modules modernized while aircraft kept moving. The integration work was the constraint, not the application code.
Case study 03
Ground handling and fueling, where a data error has an immediate cost
Multi-module ERP work for airport operations, where a wrong figure is not a reporting problem. It is a truck at the wrong stand.
Once the data flows reliably, the next question is what to do with the exceptions. That is where AI automation on top of the integrated data starts to pay: flagging the record that looks wrong before a person has to find it, and routing it to whoever can fix it.
Frequently Asked Questions
Integrating an ERP with the people who actually use it?
Tell us what the field app has to capture and which system owns the record. We will tell you what will break, before you build it.
