We design, build and operate the interfaces that connect Salesforce to the rest of your stack — ERP, payments, event streams, data warehouses and HR. This page covers how we work, the platform's integration styles, and five reference architectures we deploy in production.
Salesforce integration is the practice of connecting a Salesforce org to other business systems — ERP, billing, payments, data warehouses, HR platforms and event streams — so that data and processes stay consistent across all of them. Technically, it covers inbound and outbound APIs (REST and SOAP), event-driven mechanisms (Platform Events and Change Data Capture), high-volume batch interfaces (Bulk API), and the middleware — an ESB, iPaaS, event broker or custom services — that routes, transforms and monitors traffic between systems. A well-designed integration defines a system of record for every shared entity, a synchronisation style per interface (real-time, near-real-time or batch), and explicit rules for error handling, retries and idempotency so that repeated or failed messages never corrupt data. Integration is distinct from data migration, which moves data once; integrations run continuously and must survive deployments, API version changes and outages on either side.
Most Salesforce programmes do not fail inside Salesforce. They fail at the seams. A quote-to-cash process that looks clean in CPQ falls apart when orders reach the ERP with mismatched product codes, when invoices post twice, or when a payment settles in the provider but the opportunity still shows unpaid. The same is true for AI: Agentforce agents and analytics are only as good as the data arriving through your interfaces, at the freshness your use case needs.
Integration is also where operational cost hides. A brittle nightly job that a single admin restarts by hand is not an interface — it is a liability with a schedule. You need deliberate integration work when you recognise these signals:
The fix is rarely a bigger tool. It is architecture: a system-of-record decision per entity, a contract per interface, and reliability patterns applied consistently — the subject of our integration patterns guide.
We have built Salesforce systems since 2010 with senior engineers only — 46 certified experts across offices in Provo, Utah and Prague, which gives clients a long combined working day for build and run support. Our integration work spans telco, financial services, insurance, nonprofit, automotive and SaaS. We also run our own products on these patterns: TransactionHub pulls transactions from secure banking APIs and matches them to Salesforce records, and CollectiPro automates dunning inside Salesforce — so the patterns below are production-hardened, not slideware.
System inventory, a system-of-record decision for every shared entity, and a written contract per interface: payloads, sync style, volumes, SLAs and error semantics — before anything is built.
Platform-native where sensible — Named Credentials, External Services, Platform Events, an Apex service layer — middleware where warranted. Every interface sits behind a versioned contract so either side can evolve.
Failure injection, limit and volume testing, reconciliation jobs, dashboards and alerting. Every failure mode we can trigger gets a runbook before go-live, not after the first incident.
Handover to your team with the interface catalogue and runbooks, or ongoing operation under managed services with monitored error budgets per interface.
Deliverables always include the interface catalogue, an environment strategy for testing integrations safely, monitoring, and documentation your own engineers can maintain. See the full engineering offering under services.
Salesforce gives you four fundamentally different ways to move data. The most common architectural mistake is picking one style for everything; the right answer is one style per interface, chosen by interaction pattern and volume.
Request-response, synchronous. Use it when a user or process needs an immediate answer: a credit check during quoting, an address validation, an order status lookup. Outbound, callouts run against timeouts and daily API allocations on the other side; use Named Credentials for auth, back off on throttling responses, and never chain long synchronous call sequences inside a user transaction. Inbound, composite requests reduce round trips when a caller must touch several related records atomically.
Publish-subscribe, asynchronous, fire-and-forget. The right tool for business events — "order placed", "payment received" — that other systems consume on their own schedule. Delivery is at-least-once, so every consumer must deduplicate. Platform Events are not request-response: if the publisher needs an answer, you are designing a callback, not an event. Decide deliberately whether events publish immediately or after the transaction commits; the difference matters when the transaction rolls back.
A record-level change stream that mirrors creates, updates, deletes and undeletes with replay IDs. Ideal for keeping caches, search indexes and warehouses in sync without writing trigger code. Consumers manage their replay window; if a subscriber is down longer than the retention window, you re-baseline with a bulk extract rather than pretending nothing was missed.
Asynchronous batch jobs for high volume: initial loads, nightly synchronisation, re-baselining after an outage. Design around parallelism and record locking — parent record contention is the classic cause of failed batches — and treat job monitoring as part of the interface, not an afterthought.
Exact API allocations, event delivery quotas and Bulk job limits vary by edition and change between releases — check current Salesforce documentation during design. For a decision framework with worked examples, read Salesforce integration patterns.
Point-to-point is fine for one or two stable, low-volume interfaces with similar data models. Beyond that, an integration layer starts paying for itself: it centralises retries, transformation, protocol bridging (SFTP drops, legacy SOAP, file feeds), orchestration across systems, and monitoring in one place instead of scattered Apex.
One honest warning: middleware that merely proxies calls without adding delivery guarantees, transformation or observability is the most common anti-pattern we remove during rescues. Choose per interface, not by ideology.
These are the five interfaces we are asked to design most often. The diagrams are simplified — every real deployment adds secrets management, an environment strategy and per-interface monitoring — but the sync styles, error handling and idempotency rules shown here are the ones we ship.
Sync style: asynchronous events for the transactional flow (orders, invoices, credit status), nightly batch for master data and pricing — SAP maintenance windows must never block quote-to-order. Error handling: the middleware retries with exponential backoff, then parks the message in a dead-letter queue with alerting; a daily reconciliation job compares order counts and totals on both sides. Idempotency: the Salesforce order ID travels as SAP's external key, so redelivered messages are rejected as duplicates instead of creating a second order. Full walkthrough: Salesforce–SAP integration.
Sync style: synchronous REST calls outbound to create customers and payment intents; asynchronous webhooks inbound as the source of truth for payment state — never the browser redirect. Error handling: the webhook handler verifies signatures, acknowledges fast and processes asynchronously; failed updates retry from a queue, and a scheduled job reconciles Salesforce payment records against Stripe balance transactions and payouts. Idempotency: every mutating call carries an Idempotency-Key, and inbound events are upserted by Stripe event ID, so replays and duplicate webhooks are harmless. Details: Stripe payments on Salesforce.
Sync style: near-real-time streaming — CDC events flow through a relay into Kafka topics partitioned by record key, which preserves per-record ordering for any number of consumers; the return path writes via Bulk or REST upserts. Error handling: the relay commits its replay-ID checkpoint only after Kafka acknowledges the write; poison messages go to a dead-letter topic; a subscriber that outlives the CDC retention window re-baselines with a bulk extract. Idempotency: delivery is at-least-once end to end, so every consumer upserts by external ID rather than inserting. This is the backbone we use for composable stacks — see headless CRM on Salesforce.
Sync style: batch and micro-batch — CDC-captured changes and Bulk API extracts land in Snowflake on watermarked increments; aggregates and scores return on a schedule, or are surfaced virtually without copying. Error handling: every load writes to an audit table; row counts and watermarks are reconciled after each run, and late-arriving data is merged rather than dropped. Idempotency: loads use MERGE by key, so re-running a failed batch is safe by construction. If your org runs Data Cloud, its data-sharing options can replace parts of this pipeline — the audit discipline stays.
Sync style: Workday is the master for people data; a daily report-as-a-service extract plus event notifications drives user provisioning, role assignment and territory updates in Salesforce. Error handling: records failing validation are quarantined for HR review instead of partially applied — a half-executed org change is worse than a delayed one — while deactivations always propagate immediately for security. Idempotency: every operation keys on the employee ID, and joiner–mover–leaver ordering is enforced in the integration layer so re-runs converge to the same state.
Financial services taught us to treat every interface as something that will fail mid-message. The patterns below are mandatory in our banking and insurance work and cheap enough that we apply most of them everywhere:
For the full treatment — API gateway topology, consent flows and mainframe-era constraints — read core banking API integration.
Direct point-to-point integration works when you have one or two stable interfaces, low volume and similar data models — Named Credentials with Apex callouts or External Services are enough. Add middleware once you connect three or more systems, need guaranteed delivery, heavy transformation, protocol bridging or centralised monitoring. Middleware earns its cost by absorbing retries, mapping and orchestration that would otherwise accumulate as Apex; it adds licence cost and another platform to operate.
Match the style to the interaction. Use REST or composite calls when a user or process needs an immediate answer. Use Platform Events for business events other systems consume asynchronously. Use Change Data Capture when downstream systems must mirror Salesforce record changes without custom trigger code. Use Bulk API for large loads and re-baselining. Most real architectures combine several styles — the decision is made per interface, not per project.
By designing for limits instead of discovering them in production. We batch and debounce outbound calls, prefer events over polling, route volume through Bulk API, cache reference data and monitor daily API consumption per integration user. Allocations vary by edition and API version and change over time, so we verify current numbers in Salesforce documentation during design and keep headroom rather than sizing to the ceiling.
It depends on the number of interfaces, the maturity of the other system's APIs and how much data cleanup is involved. A single well-documented interface, such as a payment provider, is typically weeks including hardening. An ERP programme with master data governance, several interfaces and reconciliation runs months. We scope each interface separately, so you see the critical path before committing to the whole roadmap.
The main cost drivers are the number and complexity of interfaces, the transformation and orchestration logic each one needs, middleware licensing if a platform is introduced, and non-functional requirements such as audit trails, encryption and reconciliation. Regulated industries cost more than a simple SaaS sync because of compliance evidence and failure-mode testing. We quote per interface after a short discovery rather than estimating the whole programme blind.
With the same patterns banks apply internally: idempotency keys on every mutating call, a transactional outbox instead of publishing events mid-transaction, dead-letter queues with alerting, daily reconciliation between systems of record, immutable audit logs and replay tooling. We treat every interface as something that will fail mid-message and design the recovery path first. Our TransactionHub product packages several of these patterns for bank-feed processing.
Yes — a significant share of our integration work starts as a rescue. We begin with an architecture review: inventory every interface, map system-of-record decisions, measure error rates and API consumption, then stabilise the worst offenders before refactoring anything. Your business keeps running during the takeover; we replace interfaces one at a time behind stable contracts instead of attempting a big-bang rewrite.
A senior integration architect will scope it honestly — including telling you what not to build.