Executive summary
Salesforce integration is the work of connecting Salesforce to the other systems that hold your business — ERP, billing, data warehouse, marketing platform, product. Salesforce documents the mechanics thoroughly: the APIs, the patterns, the tooling. What gets documented far less is the part buyers actually get stuck on — which architecture to choose, whether you need middleware, what it will cost, and what goes wrong in production.
This guide covers all four, alongside the technical foundations. It is written for the person deciding on an approach, not the developer implementing one — though the developer will find the failure modes section useful, because most of them are design decisions rather than coding mistakes.
The main takeaway: integration projects rarely fail on the technology. They fail on data mapping nobody agreed, error handling nobody designed, and ownership nobody assigned. Choose the architecture for how much of that you can absorb.
TL;DR
- Six architectures exist; point-to-point and middleware cover most real situations, and the choice hinges on how many systems you will connect over the next three years.
- You need an iPaaS when connection count crosses roughly four to five systems, or when non-developers need to maintain the flows.
- Most production failures are design failures — unmapped fields, no idempotency, no error handling, no monitoring.
- API limits are the classic scale surprise. Design for them before you hit them.
- Cost is driven by the number of systems and the state of your data, not by which API you use.
- Integrated data is now the prerequisite for AI agents, which raises the stakes on getting it right.
Why Salesforce integration is harder than it looks
The APIs are well documented and mature. Connecting two systems in a demo takes an afternoon.
What takes months is everything around it: agreeing which system is authoritative for each field, handling records that exist in one system and not the other, deciding what happens when a sync fails at 2am, and keeping all of that working as both systems change underneath you.
A useful framing: integration is a small amount of moving data and a large amount of agreeing what the data means. The projects that go badly are the ones that treat it the other way round — which is why we approach it as a revenue operations problem before we approach it as a build.
Choosing an integration architecture
The six architectures, briefly
Point-to-point. One system connects directly to another. Simplest to build. Each additional connection adds complexity, and the total grows faster than the number of systems.
Hub-and-spoke (middleware-based). A central hub handles transfers; each system connects to the hub rather than to every other system. Easier to scale and govern. MuleSoft and Boomi are common choices.
Event-driven. Real-time triggers — something happens in one system and is published immediately. Salesforce Platform Events and Change Data Capture support this natively; Kafka is common on the enterprise side.
Data virtualization. Rather than moving data, a virtual layer surfaces external data inside Salesforce. Salesforce Connect is the native implementation. Keeps your org light and avoids duplication.
Batch-oriented. Scheduled bulk transfers — nightly syncs and similar. Lower load, higher latency. Appropriate more often than people assume.
API-led. Reusable APIs organized into system, process and experience layers. Flexible and governable; more upfront design.
How to decide between them
| If this describes you | Start here |
|---|---|
| Two or three systems, stable, no plans to add more | Point-to-point |
| Four or more systems, or more coming | Hub-and-spoke / iPaaS |
| Users need data in Salesforce but you do not want to store it | Data virtualization (Salesforce Connect) |
| Latency matters — reps need it now, not tonight | Event-driven |
| High volume, latency does not matter | Batch |
| Large organization, many teams building integrations | API-led |
The single most useful question: how many systems will Salesforce need to talk to in three years? Point-to-point at two connections is sensible engineering. Point-to-point at eight is a maintenance problem that will consume more effort than the middleware would have cost.
Salesforce’s own integration capabilities
The APIs and when to use each
| API | Use it for | Avoid it for |
|---|---|---|
| REST API | Most integrations, mobile and web services | Very large data volumes |
| SOAP API | Enterprise systems requiring strict contracts and strong typing | New builds where REST is an option |
| Bulk API | Large volumes — nightly loads, migrations, backups | Anything needing an immediate response |
| Streaming API / Platform Events | Real-time push — dashboards, alerts, event-driven flows | Guaranteed-delivery scenarios without additional design |
| Outbound Message | Simple no-code notification to an external endpoint | Anything with complex payload or error-handling needs |
| Web Service Callout | Salesforce needing live data from another system | High-frequency calls that will hit limits |
The most common mistake: using REST row-by-row where Bulk API was designed for the job. It works in test with a hundred records and fails in production with a hundred thousand.
Salesforce Connect and Heroku Connect
Salesforce Connect exposes external data as external objects inside Salesforce without storing it — good for large reference datasets you need to see but not own. Note the query and reporting limitations before designing around it.
Heroku Connect synchronizes Salesforce data with Heroku Postgres, which is how most custom applications built on Heroku stay in step with the CRM.
Do you need an iPaaS?
When point-to-point is fine
Two or three systems, stable requirements, straightforward field mapping, and someone technical who can maintain it. Adding middleware here is cost and complexity you will not recover.
When middleware starts paying for itself
- Connection count crosses roughly four to five systems.
- Non-developers need to maintain flows. iPaaS platforms are visual; custom code is not.
- You need consistent error handling, retry and monitoring across every integration rather than reinvented per connection.
- The same transformation logic is being rebuilt in several places.
- Governance matters — you need to know what is connected to what, and who changed it.
The main platforms compared
| Platform | Best suited to | Consider |
|---|---|---|
| MuleSoft | Enterprise, API-led, complex governance — Salesforce-owned, so the roadmap alignment is real | Typically the highest cost and steepest learning curve in this list |
| Boomi | Mid-market to enterprise, broad connector library | Less deep on API management than MuleSoft |
| Workato | Business-team-led automation with technical depth available | Pricing scales with recipe volume |
| Celigo | Mid-market, strong on ERP and ecommerce connections | Narrower than the general-purpose platforms |
| Zapier / Make | Lightweight, low-volume connections between SaaS tools | Not built for high-volume or complex enterprise integration |
| Custom code | Unusual requirements no platform handles | You own it forever — see custom Salesforce development |
The honest heuristic: if you are connecting a handful of mainstream SaaS tools at modest volume, a lightweight tool is fine. If ERP, billing or a data warehouse is in scope, you are in iPaaS territory.
Integration patterns
Remote process invocation — request and reply. Salesforce calls an external system and waits. Use when the user needs the answer before continuing.
Remote process invocation — fire and forget. Salesforce sends and does not wait. Use for logging and status updates where no immediate response is needed.
Batch data synchronization. Large scheduled transfers. Reduces load; accepts latency.
Remote call-in. An external system writes into Salesforce — web forms, ecommerce platforms, partner systems.
Data virtualization. Salesforce displays data held elsewhere without storing it, keeping the org light while giving users access.
Event-driven integration. Something happens; a message is published; subscribers react. The most scalable pattern, and the one requiring the most upfront design.
The ten sync failures that cause most production issues
These are design failures, not coding failures — which is why they survive testing and appear in production.
- Unmapped or partially mapped fields. Mapping gets settled during the build instead of agreed field by field in writing beforehand, so gaps surface only once real data flows.
- No idempotency. Every integration will replay a message eventually. If replaying creates a duplicate, the design is wrong.
- Silent failures. A sync that fails without alerting anyone will be discovered by a user weeks later, in a report.
- No retry logic. Transient network failures are normal. Without retry with backoff, normal becomes data loss.
- Ambiguous field ownership. Two systems both believe they own a field, and records flip back and forth indefinitely.
- Timezone and date-format mismatches. Quiet, pervasive, and hard to detect because the data looks plausible.
- Picklist drift. A value added on one side and not the other. Records fail validation or land with blanks.
- Duplicate creation on the receiving side. Matching rules that work on clean test data and fail on real data.
- API limit exhaustion. Row-by-row processing at volume, or a poorly-scoped scheduled job consuming the daily allocation before noon.
- No monitoring. Everything above is survivable if you find it in an hour. Without monitoring you find it in a quarter.
API limits, and the surprises that come with scale
Salesforce enforces API request limits per org per 24 hours, scaled by edition and license count. Integrations that behave in a sandbox routinely exhaust them in production.
What actually consumes the allocation:
- Row-by-row processing where Bulk API was the right tool
- Polling — repeatedly asking “has anything changed?” instead of subscribing to events
- Retry storms — a failing integration retrying aggressively without backoff
- Reporting and analytics tools querying via API on a schedule nobody reviewed
Design decisions that prevent it: use Bulk API for volume, prefer events over polling, implement exponential backoff, and monitor consumption as a metric rather than discovering it when writes start failing.
Security and authentication
OAuth 2.0 is the standard for authenticating integrations. Avoid username-password flows for system integrations.
Named Credentials in Salesforce let you store endpoint and authentication configuration outside code, which means credentials are not scattered through Apex classes and can be rotated without a deployment.
Least privilege. The integration user should have exactly the permissions the integration needs and nothing else. In our experience, a shared admin-level integration user is one of the most common security findings in integration audits.
Field-level security and sharing. Integrations run as a user and respect that user’s access. Data quietly missing from a sync is often a permissions issue rather than a mapping one.
Encryption and PII. Know which fields carry personal data and what your obligations are for each system in the chain, not just Salesforce.
What a Salesforce integration costs
There is no list price, and any figure quoted without knowing your systems is guesswork. What follows is what determines yours.
| Driver | Effect |
|---|---|
| Number of systems | The primary variable. Each system is a new authentication model, error path and mapping negotiation. |
| Data quality on both sides | Cleaning and reconciling data often costs more than building the integration. |
| Middleware licensing | An iPaaS is an ongoing subscription, typically scaling with volume or connection count. |
| Real-time vs batch | Real-time costs more to build and considerably more to operate. |
| Custom vs standard objects | Standard objects are well-trodden; heavily customized orgs are not. |
| Error handling and monitoring | Frequently descoped to save money, and the most reliable source of later cost. |
| Ongoing maintenance | Both systems change. An integration is a commitment, not a delivery. |
The most useful budgeting advice: whatever you scope, assume data reconciliation takes longer than you think, and do not cut monitoring to fund something else.
Integration and the agentic era
One thing has changed materially about why integration quality matters.
AI agents — Agentforce and equivalents — act on the data they can reach. An agent grounded on a CRM with duplicated records, half-populated identity fields and stale synced data will act confidently and wrongly, at volume.
Two consequences worth planning for:
- Integration quality is now an AI prerequisite, not a back-office concern. The organizations struggling with agent deployment are usually the ones with integration debt. Our list of Agentforce implementation partners covers the readiness side directly.
- Salesforce Data Cloud changes the pattern for some use cases — unifying data for grounding rather than syncing it record by record into standard objects. It is worth understanding before designing a new integration you may not need.
Also worth factoring in: revenue-stack products are moving. Salesforce CPQ is end of sale, and integrations pointed at CPQ objects will need remapping if you migrate. Design with that in view.
Working with Mountainise
Mountainise designs and builds Salesforce integrations as part of a wider Salesforce consulting and revenue operations practice. In practice that means:
- Designing the right architecture for your system count and growth, rather than the one that is fastest to demo
- Connecting Salesforce with ERP, marketing, billing and custom platforms
- Agreeing field ownership and mapping before build, in writing
- Building error handling, retry and monitoring as part of scope rather than as an extra
- Ongoing support as both systems change
The short version
The technology here is mature and well documented. What decides whether a Salesforce integration works is a small set of design choices made early: the architecture that matches your system count, explicit field ownership, idempotency, real error handling, and monitoring you will actually look at.
Choose the architecture for where you will be in three years rather than where you are now. Add middleware when connection count justifies it, not before. And never cut monitoring to fund a feature — it is the cheapest insurance in the project.
Frequently asked questions
It depends mainly on how many systems Salesforce will connect to over the next three years. Two or three stable systems: point-to-point. Four or more, or more coming: hub-and-spoke with middleware. If users need to see external data without storing it, data virtualization via Salesforce Connect. If latency matters, event-driven.
Not for a handful of mainstream SaaS connections at modest volume. Middleware starts paying for itself around four to five connected systems, when non-developers need to maintain flows, or when you want consistent error handling and monitoring across every integration instead of rebuilding it each time.
Unmapped fields, no idempotency, silent failures, no retry logic, ambiguous field ownership, timezone and date-format mismatches, picklist drift, duplicate creation, API limit exhaustion, and no monitoring. Almost all of them are design decisions rather than coding errors, which is why they survive testing.
REST for most integrations, Bulk API for large volumes, Streaming API or Platform Events for real-time push, SOAP where an enterprise system requires strict contracts, and Web Service Callouts when Salesforce needs live data from elsewhere. Using REST row-by-row where Bulk was appropriate is the most common and most expensive mistake.
It depends far more on data quality and the number of systems than on the technology. A single well-defined connection between two clean systems is weeks. A multi-system integration requiring data reconciliation and agreement on field ownership across teams takes considerably longer, and the delay is usually in the agreement rather than the build.
The drivers are the number of systems, data quality on both sides, middleware licensing if any, whether you need real-time or batch, how customized your org is, and how much error handling and monitoring is in scope. Any quote given before someone has seen your systems is a guess.
Salesforce enforces daily API request limits per org, scaled by edition and licenses. You are most likely to hit them through row-by-row processing at volume, frequent polling instead of event subscription, retry storms, or unreviewed scheduled analytics queries. Design for them rather than discovering them.
Directly. Agents act on the data they can reach, so duplicated records, incomplete identity fields and stale synced data produce confident wrong actions at scale. Integration quality has become a prerequisite for reliable agent deployment rather than a back-office concern.