Keeping Orders in Sync Without Anyone Typing Them Twice
Marketplace orders flow into Salesforce automatically, and fulfillment updates flow back
The problem
Before this, order fulfillment status lived in two places that didn't talk to each other. Someone had to check the marketplace, then update Salesforce by hand — slow, and wrong the moment volume picked up. The fix was to treat order sync as a standing pipeline rather than a task: every change on either side becomes an event, and the pipeline reacts to it within seconds instead of at the end of the day.
The shape of the flow
The pipeline runs in two directions, and each has a different job. Outbound, Salesforce is the source of truth — orders ready to ship get pulled and pushed out as fulfillment requests. Inbound, the marketplace is the source of truth for what actually happened — status and inventory changes get matched to an existing Salesforce record and written back onto it.
Scheduled pull of ready-to-ship orders — always creates a new fulfillment request.
Status & inventory events are matched by external ID and applied as updates only.
A periodic sweep catches anything a missed event left behind.
Create vs. update, decided once
The rule that keeps the two lanes from colliding: Salesforce is the only place an order gets created. Every event coming back from the marketplace is treated strictly as an update — it's matched against an existing record by external order ID, and if no match is found, it's logged and set aside rather than silently creating a duplicate. That single rule removes an entire category of duplicate-record and out-of-order-write bugs.
What a flow like this actually needs
Decouples the moment an event arrives from the moment it's handled, so a slow or failing step doesn't block the next event in line.
Webhooks and push events get missed. A periodic re-check is what turns "usually in sync" into "eventually always in sync."
Create-vs-update stops being a judgment call once every record carries a stable external ID to match against.
Any external API has a ceiling. Writing in controlled batches with small delays keeps the pipeline under it by design, not by luck.
Per-call error handling plus a dead-letter path and centralized logs mean a failure gets noticed and retried, not lost.
Internal write-up — kept intentionally high-level. For implementation specifics, see the pipeline source directly.