Systems that will not talk and nobody owns it
An integration platform bought and underused
Nightly exports standing in for real-time data
A project stalled on a data problem
The cheapest integration is the one you talk yourself out of building.
MuleSoft and Salesforce integration: ERP, finance and operations systems, API design, error handling, field-level data ownership and replay.
Every business past a certain size runs on systems that were never designed to meet. The cost is not the software, it is the people quietly reconciling it — the export, the reformat, the paste, and the follow-up email asking which number is the right one.
So we map where the same fact is stored twice, decide which system owns it, and move it on a schedule the business can actually feel. Most of what we build here is unglamorous and permanent: order data landing where the sales team already works, and finance seeing the same figure a day earlier than they used to.
Where it breaks
A file drops at 2am and half the business depends on it. When it fails, people find out from customers.
Each one built for a reason, none documented, and changing any system now means auditing all of them.
Because connecting the systems was quoted once and deferred, and re-keying became somebody's job description.
Integrations belong to whoever built them, who has usually left. Failures surface as business problems first.
Significant licensing, a fraction of the intended use, and a renewal conversation approaching.
Expectations set during the sales cycle that the architecture never actually supported.
What we build
Nine habits that decide whether an integration is still working in three years, or quietly stopped last March.
Upsert on an external ID so running the job twice changes nothing, which sounds obvious until you meet an integration where it does not.
A run log, per-file step and error records, alerting on failure, and a heartbeat job that treats silence as a failure, because the usual way a feed is found broken is somebody noticing a number looks wrong weeks later.
An error queue you can reprocess, so a bad batch costs a click rather than an afternoon of somebody retyping records.
Two systems will eventually disagree about the same customer. Naming the owner field by field, rather than system by system, is a short conversation that prevents a long argument.
The integration we build most: orders, invoices, pricing, parts and inventory mirrored into Salesforce so a rep stops asking finance a question the system already knows the answer to.
Pushing the outcome back out as a job, an order, a customer record or a pricing condition, and telling the person who created it when the push fails rather than failing quietly.
The mapping written down in a form a business analyst can read, which is what lets you change the integration in two years instead of rebuilding it.
Integration behind a customer or partner portal, so what an outside user sees is the real order and the real balance rather than a copy that drifted.
The first question is whether this needs a platform at all. Plenty of what gets scoped as an integration program is one well-built connection, and we would rather say so.
Beyond phase one
Each one came out of delivery work rather than a product roadmap. In most cases the client did not know to ask for it.
Silent failure is the normal failure mode. Most teams discover a feed stopped when somebody notices a number looks wrong, which is usually weeks. Alerting on absence costs a day and saves a quarter.
The mapping lives in a developer head, a spreadsheet, or nowhere. Writing it down in a form a business analyst can audit is what lets you change the integration in two years without rebuilding it.
Two systems will eventually disagree about the same customer. Naming the owner field by field, rather than system by system, is a two hour conversation that prevents a two year argument.
When a batch fails, the choice is a queue you can reprocess or a person retyping records. The queue is not expensive. It is just invisible in a demo, so it rarely makes the first scope.
An integration built for one destination gets rebuilt for the second. An interface built as a reusable service gets reused, and the third project is the one that pays for the discipline.
Integrations
Integration work is defined by what is on either end. These are the categories that come up most.
Usually the system of record, and usually the hardest to reach.
Sector systems with partial APIs, or none.
Warehouses and lakes that need feeding and reading.
Order capture reaching fulfilment without manual steps.
Single sign-on and provisioning across the estate.
The formats nobody chose but everybody still uses.
Ingram Micro · BlueStar · BigCommerce
Participant records spread across intake forms, phone and email, with no single view of who had actually been contacted. Outreach, texts and calls now land on the participant record itself, across a statewide partner network and more than a thousand participants.
Sales Cloud · Experience Cloud · Einstein Activity Capture · OpenPhone
QuickBooks · UPS & USPS · Sales Cloud
Every company has a pair. We will look at what each one believes, which of them ought to win, and whether this actually needs middleware or just needs somebody to make the call.
