Salesforce Integration: Patterns, Tools and How to Choose an Integration Partner

Salesforce integration is the work of connecting Salesforce to other systems, such as an ERP, a data warehouse, a marketing platform or a billing tool, so that customer and deal data moves between them automatically and consistently. Done well, it removes manual re-keying and gives every team the same version of each account, order and invoice.

This guide explains the main Salesforce integration patterns, the APIs and tools behind them, how to choose between point-to-point, middleware and custom builds, and what to look for in an integration partner. For a concrete example of a CRM-to-ERP build, see our NetSuite–Salesforce integration service.

What Is Salesforce Integration and Why Does It Matter?

Salesforce usually holds the commercial process: leads, opportunities, quotes and account history. Other systems hold the rest of the picture. The ERP owns orders, invoices and payments. The data warehouse owns reporting history. The support platform owns tickets. Without integration, people copy data between these systems by hand, and the copies drift apart.

Integration matters most at the handoffs between teams. A closed deal that has to become an order, a customer who changes a billing address, or a service case that depends on contract terms are all moments where a missing or late update causes a visible failure. The goal is not to connect everything. It is to connect the specific flows where a delay or a mismatch hurts the business, and to decide which system owns each piece of data.

That ownership decision is the first design step in any project. For each object and field, name one system of record, one direction of change and one rule for conflicts. Most failed integrations skip this step and try to fix it later with more code.

What Are the Main Salesforce Integration Patterns?

Integration patterns describe how data moves: in which direction, how quickly and who starts the exchange. Most real projects combine two or three of them. The table below summarizes the patterns that appear most often.

A useful rule of thumb: use real-time calls only where a person is waiting for the answer, use events or messages where another system needs to react quickly, and use batch jobs where volume matters more than speed. Choosing real time for everything makes the integration fragile, because every flow then depends on every other system being available at that moment.

Which Salesforce APIs and Mechanisms Support Integration?

Salesforce exposes several interfaces, and each fits a different pattern. Choosing the right one for each flow matters more than choosing a single favorite.

• REST and SOAP APIs. General-purpose interfaces for reading and writing records. REST suits modern services and lightweight clients, while SOAP remains common in older enterprise tools.
• Bulk API. Built for loading or extracting large volumes of records asynchronously, which makes it the usual choice for migrations and warehouse loads.
• Platform Events and Change Data Capture. Event mechanisms that publish custom business events or record changes so that other systems can subscribe to them.
• Pub/Sub API. Salesforce describes it as a single interface for publishing and subscribing to platform events (opens in new tab), built on gRPC and HTTP/2 with messages in the Apache Avro format.
• Apex callouts and outbound messaging. Ways for Salesforce itself to call an external service when something happens inside the CRM.
• External services and data virtualization. Features that let Salesforce use an external API or display external records without copying them.

Every one of these interfaces has usage limits and security settings that depend on the Salesforce edition and the way the org is configured. Design for those limits from the start: batch where volume is high, retry where a call can fail, and avoid chatty designs that make many small calls for one business action.

Which Salesforce Integration Tools Can You Use?

Teams generally choose among four approaches. None is best in every case, and many organizations use more than one.

Salesforce also sells its own integration platform, and several independent iPaaS vendors offer Salesforce connectors. The product matters less than the fit: how many systems you connect, how complex the business rules are, and who will operate the integration after launch.

How Do You Choose Between Point-to-Point, Middleware and a Custom Build?

Start from the number of systems and the complexity of the rules, not from the tool. A single connection between Salesforce and one other system rarely needs a platform. Five systems exchanging overlapping data almost always do. The table below gives a practical decision guide.

Point-to-point connections look simple at first, but each new system multiplies the number of links to build and maintain. If you expect the list of connected systems to grow, put a shared layer in place early, even if the first project only uses a small part of it. Our guide to systems integration covers the broader trade-offs between these architectures.

What Are the Most Common Salesforce Integration Challenges?

Most problems come from design choices, not from the APIs. Four come up again and again.

• Unclear data ownership. Two systems both update the same field, and the last write wins. Define one system of record per field and write the conflict rule down.
• Duplicates and retries. A retried call creates a second order. Make operations idempotent, so that repeating a message produces the same result as sending it once.
• Poor visibility. Failures happen silently and are found by customers. Log every message, expose failed ones in a queue and alert a named owner.
• Access creep. Integration users often receive broad permissions for convenience. Grant each connection only the objects and fields it needs, a risk we cover in connecting Slack, SharePoint, Salesforce and Drive without leaking scope.

Data quality is a fifth, quieter challenge. Integration exposes inconsistencies that were easy to ignore when each system stood alone: duplicate accounts, free-text fields that should be picklists, and records without an owner. Plan a cleanup pass before the first sync, and set validation rules so that new data enters the system in a usable form.

How Do You Plan and Run a Salesforce Integration Project?

A predictable sequence keeps the project small enough to deliver and safe enough to run in production.

Treat the first release as the start of operations rather than the end of the project. Someone must own monitoring, handle exceptions and update mappings when either system changes.

How Do You Choose a Salesforce Integration Partner?

A good partner reduces risk in the parts of the project that are hardest to see from the outside. Use these questions when you compare Salesforce integration services:

• Do they start with data ownership and flows, or with a tool? A partner who proposes a platform before understanding your processes is selling a product, not a design.
• Can they explain how failures are handled? Ask about idempotency, retries, logging and who is alerted when a message fails.
• Do they work on both sides of the connection? The CRM and the target system, such as an ERP, each have their own constraints, and the integration has to respect both.
• Is there a clear path from assessment to operation? Look for a defined first phase that fixes scope and complexity, followed by implementation and ongoing support.
• Will your team be able to run it? Documentation, monitoring and a handoff plan matter as much as the code.

Sphere approaches CRM-to-ERP work this way. In its NetSuite–Salesforce integration service, Salesforce handles the commercial process and NetSuite handles operational and financial execution, with an integration layer that validates updates, maps records and uses idempotency and logging so that each record is created only once and every transaction stays traceable. The work begins with an integration assessment that defines scope, flows and complexity. Scope and investment are agreed with each client during that assessment.

If you need Salesforce engineers inside your own team, Sphere also offers Salesforce developers, including integration specialists. For the supporting data work, such as pipelines into a warehouse, see our data engineering services, and for automating the processes that sit on top of the integrated data, see intelligent automation. If your goal is to connect Salesforce data to AI features, our guide to generative AI integration explains how to add them to existing systems.