A work order nobody can invoice is just a note.

The ERP should own the item master, costing and warehouse stock, because that is where purchasing and finance already live. Field Service should own van stock and consumption at the point of work, because that is where the movement actually happens. The failure mode is both systems believing they own the same number — Field Service deducting a part at debrief while the ERP deducts it again at goods issue. The integration's job is to make each movement travel exactly once, in one direction, with a shared key.

It depends on how many integrations you will genuinely end up with, not on how many you are building today. For one or two stable connections, a direct API build is often cheaper to own and has fewer moving parts. From about three upward, an integration platform such as MuleSoft, Celigo or Boomi usually wins, because monitoring, retry, failure queues and replay come with the platform instead of being rebuilt per connection. The honest test is whether you want to own error handling yourself — that, more than connector availability, is what you are buying.

Filtering and de-duplication before anything reaches Salesforce. Connected equipment emits far more events than are worth a truck roll, so the design question is which threshold combinations genuinely indicate a fault, how long a condition must persist before it counts, and whether an open work order already exists for that asset. Done properly, a threshold breach creates a work order against the specific asset before the customer notices. Done without filtering, dispatchers learn to ignore the alerts within a fortnight and the investment is wasted.

Yes. The technical work is moving assets, service history, contracts and open work with their relationships intact; the hard part is deciding how much history is worth bringing. Full history makes reporting continuous but carries every data quality problem the old system had. We usually migrate assets and contracts completely, migrate service history for a defined period, and archive the rest somewhere retrievable. Nothing cuts over until a parallel run reconciles — if the numbers do not agree in both systems for a full cycle, the migration is not finished.

That is a design question, and it is the one most integration projects answer too late. Every flow needs a defined failure behaviour: whether the record retries automatically and how many times, whether it lands in a queue a named person actually monitors, whether downstream processing should halt or continue, and whether replay must preserve ordering. We build the failure queue and the replay mechanism as part of the integration rather than after the first incident, because retrofitting ordering guarantees into a live integration is considerably harder than designing them in.

No, and assuming it does is expensive. Item masters, price books and customer records change slowly and belong in scheduled batches. Stock levels usually need to be near-real-time only for the locations dispatch actually checks before assigning work. Genuinely immediate flows are a short list: emergency work order creation, IoT fault events, and appointment status updates that customers are watching. Making everything real-time consumes API capacity that the flows which truly need immediacy then cannot get, so the design starts by asking what breaks if a given flow is twenty minutes late.