Service

Enterprise integrations

An integration is easy to demonstrate and hard to operate. The interesting questions are not about the protocol: they are about which system owns which field, what happens when the same message arrives twice, and who gets paged when the queue backs up. We design those answers explicitly and build the interface around them.

The work

System-of-record mapping: which system owns each entity and field, and in which direction it may change
Interface design across Salesforce, ERP, finance, and operational systems — including MuleSoft-based delivery where it fits the landscape
Idempotency, retry, and replay behaviour, with a dead-letter path for messages that cannot be processed
Reconciliation jobs that detect divergence between systems rather than assuming it away
Operational instrumentation: what is logged, what is alerted on, and what a first responder can actually do about it

Where we stop

We design and implement integrations for a specific customer landscape after discovery. We do not sell prebuilt connectors, and the systems listed in our integration catalogue describe delivery capability and past experience — not shrink-wrapped products.

The decisions this work exists to get right

System-of-record boundaries: Enterprise landscapes rarely have one source of truth. A customer record may be mastered in Salesforce while pricing is mastered in the ERP and entitlements somewhere else. We write the ownership matrix down per field and per direction, because every later conflict-resolution argument resolves back to it.
Idempotency and redelivery: Any interface that can retry will eventually deliver the same message twice. Stable business keys, deduplication, and idempotent writes are designed in from the start, so a retry is a non-event rather than a duplicate order.
Failure paths as first-class design: Retry policy, backoff, dead-letter queue, and replay tooling are part of the interface specification, not an operations afterthought. A message that cannot be processed must end up somewhere a human can see it and act on it.
Change events versus polling: Platform Events, Change Data Capture, and scheduled extraction have different durability and replay characteristics. The choice follows the recovery requirement and the volume profile, not a preference for the newest mechanism.
Who operates it afterwards: An interface without a named owner on both sides degrades quietly. We agree that ownership during design, including who watches the error queue and who has authority to prioritise a fix.

Reference architecture · bidirectional interface

Salesforce
System of record for
Opportunity, Quote, Account relationship
Writes an outbound event on state change
Integration layer
Owns
Mapping, sequencing, retry state
Deduplicates on a stable business key
ERP
System of record for
Order, Invoice, Pricing, Stock
Returns an acknowledgement with its own identifier

Ownership: Each field has one writing system and one direction. Conflicts resolve to the matrix, not to whoever wrote last.
Idempotency: A stable business key plus deduplication means a redelivered message is a no-op rather than a duplicate order.
Retry & dead-letter: Transient failures back off and retry. Anything unprocessable lands in a queue a human can see and replay.
Reconciliation: A scheduled comparison detects divergence between the two systems instead of assuming the interface held.

Generic reference architecture. The actual interfaces, ownership matrix, and operating responsibilities are defined per engagement during discovery.

Questions we get asked

Answers are here in the page rather than hidden behind a script — open or closed, the text is the same.

Do you have a ready-made connector for our ERP?

No, and we would be careful of anyone who says they do without seeing your landscape. Each implementation depends on your ERP product, version, supported interfaces, and operating model. Our team has delivered Salesforce-to-SAP and ERP integration work with MuleSoft; the catalogue on our solutions page marks exactly what is delivered experience and what is project-based capability.

Can you guarantee no data is lost?

No honest engineer can guarantee that as an absolute. What we can do is design the mechanism: idempotent writes, a documented retry and backoff policy, a dead-letter queue for messages that cannot be processed, reconciliation that detects divergence, and an audit log that lets you prove what happened.

Do we need MuleSoft?

Only if it fits. MuleSoft is a good answer when you already run it, or when the orchestration and reuse genuinely justify the platform cost. For a small number of point-to-point interfaces it is often an expensive way to solve a simple problem.

Working on something like this?

Tell us the systems and the constraint. You will get an engineer's answer, not a capability deck.

Talk to an engineer