What Is Salesforce Integration?

Salesforce integration is simply the process of connecting Salesforce with the other tools that your business is using so they can share information automatically.

Otherwise, your customer data spreads across multiple systems that don’t talk to each other. But when you integrate all those platforms together, it brings everything under one umbrella.

Like one of the Clickup ads says: Work is pain in the APPS. (LOL)

So to do away with that pain, you need integration.

For example, Company A connects Salesforce with its ERP system, marketing platform, accounting software, eCommerce store, or customer support application. The moment Salesforce integration takes place, the information can move between them automatically. It’s like forming a stream of information enabling everyone that’s working with the same data.

TL;DR: Your business uses Shopify for online sales, HubSpot for marketing, and QuickBooks for accounting, integrating them with Salesforce means your teams no longer have to switch between multiple systems to piece together customer information. Sales can see recent purchases, marketing can track campaign engagement, and finance can access invoice details, all from within Salesforce, giving everyone a complete picture while at the same time giving them the piece they’re looking for.

Related Guide: How Much Does Salesforce Integration Cost? The Only Guide You’ll Ever Need

Why Businesses Reach a Point Where Salesforce Integration Becomes Necessary

Integrating Salesforce is not your typical C-suite’s first thought when companies grow. So let’s think of it in a very one-step-at-a-time fashion.

Companies don’t grow overnight, right?

So what happens when they grow one step at a time? One of the things that definitely happens is more tools.

More tools.

More resources.

More data.

More fragmentation.

More disconnection between all platforms and data.

One day the C-Suite realizes that growth is not all lala land and that now the work has become “pain in the apps”. (love that phrase BTW LOL)

So what happens next is that they’re juggling between a dozen platforms, and none of the platforms are connected to one another.

In fact, the average organization now uses more than 100 software applications, according to BetterCloud’s 2025 State of SaaS Report. Now think about the amount of applications, software, and platforms that larger companies are using to track and manage data and operations? I’ll not be surprised even a little if the number is several hundred applications across departments.

So, the point is, as teams begin using different systems, information naturally becomes fragmented.

IBM defines data fragmentation as information being spread across different applications, databases, and platforms rather than existing in one centralized location.

SO, WHAT DOES THAT MEAN IN PRACTICE AFTER ALL? WHY DOES IT EVEN MATTER?

Well, in practice, this means everybody’s operating with one eye open. Sales may not know that a customer has an open support ticket while your finance guy is unaware of upcoming opportunities in the pipeline – so the poor soul can’t even make projections anymore. Now my personal favorite, that one marketing guru in your department that will continue sending campaigns to customers who have already canceled their subscriptions. It’s like the Japanese holdouts soldier that hid in the trenches, didn’t know WWII was over and didn’t believe a single letter they received from their families stating that the war was long over.

Shenanigans aside, the consequences go beyond inconvenience. For 12+ years I’ve been seeing what the research already suggests. In fact, one of the research highlighted by HubSpot finds that 34% of businesses lose their revenue just because of fragmented customer data. Here’s the truly funny (painfully) part. Only 9% of organizations fully trust their data for accurate reporting and 92% of companies believe that valuable customer insights/data exist outside of their CRM. I can personally testify to this. C-Suite, and everybody across the board for that matter, just know when the systems are broken. They’re just afraid to say it out loud in meetings due to the consequences and gotchas and everything else that comes as part and parcel of this mess. But when someone (usually from the C-suite) has had enough and finally decides to do something about the gut feeling, that’s when everybody across the board speaks up and shares everything that’s wrong with the system. But even at that it’s not outright. As a consultant, I’ve had to speak with every department separately, like a therapist, or clinical psychologist because 90% of the times, the collective team meetings led by the CEO is just a huge echo chamber. Everybody repeats and paraphrases what the CEO already said. So as a Salesforce integration consultant, you have to go the extra mile and speak to every department’s head and people separately if you want to know what’s WRONG.

So let’s take a typical mid-sized business as an example.

Marketing generates leads through HubSpot.

Orders come through Shopify.

Invoices are handled in QuickBooks.

Customer service operates through Zendesk.

Sales teams manage opportunities in Salesforce.

Each department sees only a portion of the customer journey. Leadership meetings become exercises in reconciling spreadsheets rather than discussing strategy because every report tells a slightly different story.

Eventually, the issue stops being about software and becomes a business problem. At that point, integrating Salesforce with the rest of the technology stack becomes less of a technology initiative and more of a necessity. This is often when organizations turn to Salesforce integration consulting services to evaluate their architecture, eliminate data silos and design an integration strategy that aligns with long-term business goals. In other words, businesses rarely adopt Salesforce integration because they want another project to manage. They adopt it because, at a certain stage, disconnected systems become more expensive and more difficult to live with than integrating them.

How Salesforce Integration Works

Salesforce integration – the meaning beyond this jargon – simply is allowing Salesforce to communicate with all the other platforms that your organization is hosting or has its data on.

It can be 1 platform.

5 platforms.

25 platforms.

Salesforce integrates with all of those very comfortably.

But now the question is, how? How does that happen?

So for example, your business uses Shopify to sell and Salesforce to manage all your customers’ data. How can you integrate Shopify with Salesforce? Well, simply with the help of API.

So when a customer purchases something, their info flows through the API connection and straight into your Salesforce. Your sales rep sitting on the other end immediately sees what the customer purchased WITHOUT having to go through the manual labor of updating records and switching between applications.

But now, how does the process look like?

🎵It starts with (one thing)… And that one thing is a source system. That can be ERP, accounting software, eCommerce platform, marketing automation tool. Basically a SOURCE where the data originates.

2️⃣Salesforce – receives, and sends, or updates information based on the business requirements. This is where it’s important for the salesforce integration consultant or the salesforce consulting partner that you’ve hired that they understand how your business works. Here, instead of my mentioning my own experience, which I’ve been mentioning quite a lot lately in this blog, I’d rather quote Girish Songirkar, he said “The primary challenge faced when integrating CRM and ERP applications is not how technically complex they are – with data mapping or API processing volume – but rather the disconnect between business definitions held by the various department stakeholders…”

He further added “One of my first experiences with a large enterprise customer that operated multiple manufacturing plants entailed designing a sophisticated data synchronization model between its CRM and ERP systems, which were also very accurately engineered. We had done complete field mapping, ensured that all implementation limits were honored via throttling mechanisms, and took every precaution to ensure the accuracy/integrity of data. However, there was considerable friction between both departments during the implementation process. The cause of the friction was due to a disparity in policy. Sales defined a closed opportunity as a signed contract; however, Finance could not recognize revenue from an opportunity until it had an approved order entry in its ERP”

3️⃣Then you need an API or integration platform. That is what acts as the bridge between the systems. Basically handles the communication between both platforms.

4️⃣Data synchronization. This is what ensures that both of the systems remain up to date. That’s where you can come and decide the frequency, you can either keep it to real-time or intervals. Up to you to decide.

1. Every Integration Starts With Two Systems

Every Salesforce integration involves at least two systems. One system acts as the source of the information, while the other consumes or updates that information. These systems might include ERP software, marketing platforms, ecommerce applications, databases, customer support tools, or even another Salesforce org.

For example, an ecommerce company might use Shopify to manage orders and Salesforce to manage customer relationships. Whenever a customer places an order, Shopify becomes the source system and sends that information to Salesforce, where sales and support teams can access it.

In other scenarios, Salesforce itself may act as the source. For instance, when an opportunity is marked as “Closed Won” in Salesforce, that information may be sent to NetSuite so the finance team can begin invoicing.

2. Data Moves Through a Connection Layer

NEWSFLASH: The systems themselves do not communicate directly by magic. They rely on a connection layer that acts as a bridge between them. This bridge may consist of APIs, middleware platforms, native connectors, or integration tools.

Think of this layer as a translator between systems. It ensures that information leaving one application is properly understood by another, even if both systems store or organize data differently.

For example, Salesforce and SAP may structure customer information differently. The connection layer helps translate and route that information so both systems can exchange data reliably and without burdenizing you with the organization of data.

3. Systems Exchange Information

Once a connection has been established, systems can perform different operations on each other’s data. 

They can:

• Create new records.
• Retrieve existing records.
• Update records.
• Delete records when necessary.

Suppose a customer places an order through Shopify. The order information is sent to Salesforce, where a customer record is created or updated automatically. Later, if the customer’s address changes, Salesforce can send the updated information back to Shopify or another connected system.

This automatic exchange removes the need for employees to manually enter the same information in multiple applications and helps ensure everyone is working with accurate data.

4. Information Can Flow in Different Directions

Just like us humans, not all integrations work the same way. Some of those involve information flowing in only one direction, while on the other hand, others DEMAND systems to continuously exchange updates.

One-Way Integration

In a one-way integration, one system sends information while the other simply receives it.

For example, an ERP system might periodically send invoice information to Salesforce so that sales representatives can view payment status without accessing the ERP directly.

Two-Way Integration

In a two-way or bidirectional integration, both systems continuously share updates with each other.

For instance, HubSpot and Salesforce may synchronize leads in both directions. If marketing updates a contact in HubSpot, Salesforce reflects the change. Similarly, if a salesperson updates information inside Salesforce, the marketing platform receives the latest data as well.

5. Data Can Be Synchronized in Different Ways

Information does not always have to be transferred instantly. Depending on business requirements, synchronization can happen in real time or at scheduled intervals.

Real-Time Synchronization

Real-time synchronization updates systems immediately whenever changes occur.

For example, when a support ticket is closed, Salesforce can instantly notify another system so the customer receives an automatic email confirmation. Real-time integrations are particularly useful when businesses require immediate visibility into changes.

Real-time synchronization has become undeniably important. IDC data (IBM) shows 63% of enterprise use cases require data to be processed within minutes to remain useful – that’s what makes real-time integration absolutely critical for customer service, operations, and decision-making.

Scheduled or Batch Synchronization

Some information does not need to be updated every second. In these cases, systems exchange data at predefined intervals, such as every hour or once per day.

For example, a company might synchronize financial data between Salesforce and its accounting system overnight. This approach is often sufficient for reporting and large-volume data transfers.

6. Business Processes Continue Across Systems

Salesforce integration is not just about moving data from one application to another. In many cases, it allows entire business processes to continue seamlessly across multiple systems.

Imagine a company using Salesforce, NetSuite, and a warehouse management system. Once a sales opportunity is marked as closed in Salesforce, an invoice is automatically generated in NetSuite. The warehouse system is then notified to prepare the shipment, and tracking information is sent back to Salesforce.

Although several systems are involved, the process appears seamless to users because the integration coordinates activities behind the scenes.

At the end of the day, organizations are adopting more applications. And as organizations continue to do it, they make process integration even more important. In fact, the global data integration market is projected to grow from $15.18 billion in 2026 to $30.27 Billion by 2030. That insane growth means only one thing – connected business processes just got more important than before.

7. Behind the Scenes, Integration Relies on APIs and Integration Platforms

Although the process may seem simple from the user’s perspective, Salesforce integrations rely on various technologies behind the scenes. APIs, middleware platforms, and native connectors enable systems to communicate, route information, and maintain consistency across applications.

According to MuleSoft’s 2026 Connectivity Benchmark Report, the average enterprise manages 957 applications, yet only 27% of them are connected. Organizations furthest along in their AI and agentic transformation journey manage an average of 1,057 applications, highlighting the growing complexity of enterprise technology ecosystems. (You’ll have to download the report after filling the form)

As a result, businesses increasingly rely on APIs and integration platforms and also middleware solutions to bridge disconnected systems and automate workflows along with maintaining data consistency across their tech stack.

The specific technologies and architectures used depend on factors such as data volume, complexity, security requirements, and the number of systems involved. In the following sections, we’ll explore these architectures, capabilities, and integration patterns in greater detail.

Why Salesforce Integration Matters Even More in the AI Era

AI, automation, and agentic workflows depend on clean, connected, governed data.

If customer data is fragmented across Salesforce, ERP, marketing platforms, service tools, data warehouses, and legacy systems, AI agents cannot act with full context. They may miss key details, duplicate work, recommend the wrong action, or operate inside isolated data silos.

Integration has become a major AI-readiness issue. Around 95% of organizations identified integration as a hurdle to implementing AI effectively, while 96% said the success of AI agents depends on seamless, debt-free data integration. At the same time, 50% of AI agents were operating in isolated silos, and only 54% of organizations had centralized governance frameworks.

That means Salesforce integration is no longer just a CRM operations topic.

It is part of the foundation for Customer 360, enterprise AI, workflow automation, data activation, and secure cross-system orchestration.

Types of Salesforce Integration

Data Integration

Data integration’s main purpose is to keep information CONSISTENT across Salesforce and all your external systems. Given its purpose, the goal then becomes simple; making sure that all the records including Accounts, Contacts, Opportunities, Orders, or Products remain synchronized, regardless of where they originate.

So let’s say that your company is using SAP for finance, Salesforce for CRM, and Snowflake for analytics. Classic btw. Anyways, so in this case, data integration makes sure that customer records, invoices, and order information remain consistent across all three of your systems.

Now from a technical standpoint… Data integration can be implemented through:

• REST API
• SOAP API
• Bulk API
• Change Data Capture (CDC)
• Platform Events
• ETL and ELT tools
• MuleSoft
• Boomi
• Jitterbit
• Skyvia

Given that, data synchronization can occur in one of the two ways:

Real-Time Synchronization

Records are updated immediately. In fact, as soon as changes occur.

So let’s say one of your customers’ address changes in Salesforce. Your ERP system receives this update instantly.

Real-time integrations are commonly built using:

• REST APIs
• Platform Events
• Streaming API
• Change Data Capture

Batch Synchronization

Data is exchanged periodically, such as every hour or every night.

In this case, Salesforce exports customer activity into a Snowflake data warehouse every evening for reporting purposes.

Batch integrations commonly use:

• Bulk API
• ETL tools
• Scheduled jobs

Salesforce’s Bulk API is krazy. It can process up to 100 million records within a rolling 24-hour period. That’s what makes it suitable for large-scale migrations and enterprise data loads.

Data integration projects often require Salesforce consultants like me to address challenges such as:

• Duplicate records.
• Master Data Management (MDM).
• External IDs and upserts.
• Data transformation.
• Mapping inconsistencies.
• Data quality and governance.

This is the most common type of Salesforce integration, and it forms the foundation of many Customer 360 initiatives.

Application Integration

This is one of my favorite ones… This is all about connecting Salesforce with other applications so they can communicate and exchange information. But please don’t confuse it with data integration. It’s because that’s primarily concerned with records. Application integration is more about enabling entire systems to work together.

To make it easy, here are a few examples:

• Salesforce and HubSpot
• Salesforce and Shopify
• Salesforce and Zendesk
• Salesforce and Slack
• Salesforce and Microsoft Teams
• Salesforce and NetSuite

Notice how in all of these scenarios, each of these applications perform a specific function while integration ensures information moves easily between the platforms.

Application integration is usually implemented using:

• REST APIs
• SOAP APIs
• Middleware platforms
• Native connectors
• MuleSoft Composer
• Zapier
• Make.com
• Boomi

So now let’s look at an example…

When a new customer places an order on Shopify:

1. Shopify sends order information to Salesforce.
2. Salesforce updates the Account and Opportunity records.
3. NetSuite generates an invoice.
4. Slack sends a notification to the operations team.

Although four different applications are involved, users experience a single connected workflow.

Now that’s exactly why Salesforce application integration is now becoming increasingly important. More than ever I’d say especially as organizations continue to expand their technology stacks. It’s no surprise, as we’ve well established in the beginning of this blog post that it’s pretty common for big enterprises to juggle between dozens of apps. In fact, According to MuleSoft’s Connectivity Benchmark Report, enterprises use hundreds of applications.

… And that, ladies and gentlemen, is exactly why integration is becoming essential everyday. It’s about staying efficient. Operational efficiency is the buzzword we use in the industry, but all that means is basically the ability to maintain or increase efficiency throughout the chain of operations.

3. Process Integration

Process integration connects business processes (example later on) that are spread/span across different systems. The cool thing about this is eliminating manual intervention because instead of exchanging data, it makes sure that a sequence of actions can continue automatically across applications without needing or requiring a person to intervene.

For example:

1. Your sales rep marks an Opportunity as Closed Won in Salesforce.
2. The integration automatically triggers invoice creation in NetSuite.
3. Notifies the ERP system to reserve inventory and update the shipping platform to begin fulfillment. 

Now you see how many systems are involved. All different. Yet the entire workflow feels smooth as a butter… and that’s the whole point of this.

It’s not like data integration, which primarily synchronizes records. Process integration primarily concerns itself with orchestrating activities and maintaining business continuity across systems – as its name suggests.

This type of integration is commonly used for:

1. Quote-to-cash
2. Lead-to-revenue
3. Order-to-fulfillment
4. Customer onboarding
5. Case management processes.

Processes. From A to Z. From Point X to Point Y. If you want a process to run without having to intervene in the middle – this is what you need.

Common implementations:

• Platform Events
• Salesforce Flow
• Apex Callouts
• MuleSoft Anypoint Platform
• Enterprise Service Bus (ESB)
• API-Led Integration Architectures
• Event-Driven Architectures

Process integration is becoming important everyday… And it’s simply because when organizations scale, by the time they’re scaling and reached the point of scale, they’re already using dozens of applications. The data is spread across. The process is heavily dependent on two things, 1) every member of your team understands the process – which is still possible, but 2) they meticulously and flawlessly implement each step of that process to make it all work… which is, I mean, let’s not even say wild… but to believe it screams La La land… It just doesn’t happen.

4. User Interface Integration

Okay so your team is maintaining data on multiple systems, but there’s not a single place / platform where everyone can go for complete information.

That’s the problem UI Integration solves. It gives users a unified experience when it comes to presenting information. It sources info from multiple systems and presents it in a single place. So instead of switching between different applications, you can see and interact with data within Salesforce that’s coming in from external systems.

So now let’s take an example. (Notice how nearly all examples feature a customer service rep like a lab rat, LOL). So, let’s say your customer service rep working in Salesforce needs access to invoice information stored in SAP, or needs order details stored in Shopify. If the UI integration is in place, this information will be readily available inside Salesforce, allowing your sales rep to access everything they need without leaving the platform.

Unlike data integration, which moves information between systems, user interface integration improves the user experience through organized presentation of data being sourced from multiple applications through a single screen. 

Salesforce consultants and solution architects commonly implement user interface integration using:

• Lightning Web Components (LWC)
• Salesforce Canvas
• Visualforce Pages
• Embedded Applications
• External Objects
• REST APIs
• Apex Callouts

5. Virtual Integration

This one is awesome. So let’s say you want Salesforce to access or interact with data that’s stored in one of the external systems, and you don’t want a physical import or you don’t want that data to be duplicated, so what you do is virtually integrate Salesforce and just when that information is needed, it’s literally retrieved in real time – whenever users or processes need it. That’s what allows organizations to maintain a single source of truth without having to replicate the data unnecessarily.

Common implementations::

• Salesforce Connect
• External Objects
• OData Services
• REST APIs
• SOAP APIs
• Apex Callouts

Salesforce Integration Security and OAuth Governance

Security needs to be designed into Salesforce integrations from the start.

Salesforce recommends using an API-only integration user, and newer guidance favors External Client Applications over older patterns such as connected apps or SOAP login for integrations. OAuth 2.0 flows remain standard, but the governance expectations around authentication, authorization, scopes, and app approvals have become stricter.

This matters because recent Salesforce-related security incidents have often involved OAuth approvals, tokens, third-party app trust relationships, or external application connections rather than core Salesforce vulnerabilities.

A secure Salesforce integration strategy should include minimized OAuth scopes, segregated integration users, controlled app approvals, token governance, app inventory reviews, authentication monitoring, and alerts for suspicious behavior.

Salesforce Integration Architecture

Basic Architecture

1. Point-to-Point Integration

This is a pretty straightforward one… This is when each system communicates directly with every other system through individual connections. One of the tricky things, I’d say, about this architecture is that it’s inexpensive if you’re operating a few applications. But it quickly becomes difficult to maintain and scale as you add more systems. So just keep that in mind while dealing with point-to-point.

• Direct one-to-one connections.
• Easy to implement.
• Low initial cost.
• Difficult to scale.
• High maintenance overhead.

2. Hub-and-Spoke Integration

This is the second basic architecture, hub-and-spoke, and this is also pretty easy to understand. This architecture has a central hub that manages communication between all of the connected systems. So instead of creating multiple direct connections, each application only needs to connect to the hub – and it’s game. So what’s the point of doing that? Organization. Keeping things clean and minimalistic. That makes the architecture easier to manage and expand.

• Every system connects to the hub.
• Centralized routing and communication.
• Easier to manage than point-to-point.
• Simplifies adding new systems.
• Single point of failure.

3. Enterprise Service Bus (ESB)

An ESB extends the hub-and-spoke model by providing advanced capabilities such as routing, orchestration, transformation, and security. It is designed for complex enterprise environments where many systems need to exchange information reliably.

• Distributed services architecture.
• Intelligent message routing.
• Data transformation and orchestration.
• Supports large-scale integrations.
• Highly scalable but more complex to maintain.

Intermediate Salesforce Integration Architectures

4. API-Led Integration Architecture

Uses reusable APIs to connect systems. Exposes data and services across applications.

• System, Process, and Experience APIs.
• Highly scalable and reusable.
• Reduces integration complexity.
• Popular in MuleSoft implementations.
• Easier to maintain and extend.

5. Event-Driven Architecture

Triggers actions across systems using events. Does not require direct communication.

• Publisher-subscriber model.
• Supports asynchronous communication.
• Enables near real-time processing.
• Loosely coupled architecture.
• Ideal for high-volume environments.

6. Microservices Architecture

This one’s interesting… It breaks applications into independent services to enable them to communicate through APIs or events.

• Modular and independent services.
• Faster deployments and updates.
• High scalability and resilience.
• Easier fault isolation.
• Common in cloud-native applications.

7. Hybrid Integration Architecture

Combines multiple approaches including cloud, on-premise, and other such integration approaches into a one big unified ecosystem.

• Connects legacy and modern systems.
• Supports diverse environments.
• Flexible and adaptable.
• Common in large enterprises.
• More complex to govern and manage.

Advanced Salesforce Integration Architectures

8. Service-Oriented Architecture (SOA)

Organizes business functions into reusable services that can be consumed by multiple applications.

• Promotes service reusability.
• Supports loosely coupled systems.
• Simplifies enterprise integrations.
• Foundation for many ESB implementations.
• Common in large organizations.

9. Mesh Integration Architecture

Distributes integration responsibilities across domains instead of relying on a central hub.

• Decentralized integration model.
• Domain-driven approach.
• Eliminates central bottlenecks.
• Improves team autonomy.
• Suitable for large-scale digital enterprises.

10. Data Fabric Architecture

Data fabric architecture basically creates a unified data layer to provide consistent access to information across multiple systems and environments.

• Enables data access across silos.
• Supports real-time analytics.
• Reduces data duplication.
• Improves governance and visibility.
• Popular in modern data ecosystems.

11. Serverless Integration Architecture

Uses cloud-based services to execute integration logic without managing infrastructure.

• Event-driven and highly scalable.
• Reduces operational overhead.
• Pay-as-you-go model.
• Faster deployments.
• Common with AWS Lambda and Azure Functions.

12. iPaaS (Integration Platform as a Service) Architecture

Connects applications, data, and processes using cloud-based integration platforms.

• Centralized integration platform.
• Low-code and no-code capabilities.
• Prebuilt connectors and templates.
• Faster implementation cycles.
• Examples include MuleSoft, Boomi, Jitterbit, and Informatica.

13. Data Mesh Architecture

Treats data as a product.

• Distributes ownership across business domains.
• Domain-oriented architecture.
• Decentralized data ownership.
• Improves scalability.
• Encourages self-service data access.
• Designed for large, data-driven organizations.

14. Cloud-Native Integration Architecture

Cloud-Native integration architecture is specifically designed for cloud applications and distributed environments.

• Built around APIs and microservices.
• Supports continuous deployment.
• Highly scalable and resilient.
• Optimized for SaaS ecosystems.
• Widely adopted in modern enterprises.

15. Middleware, ESB, and iPaaS

Middleware, ESB, and iPaaS platforms create a more centralized integration layer.

They can handle routing, transformation, security policies, API governance, retries, monitoring, and reusable integration assets. This is especially useful when Salesforce needs to connect with ERP, marketing automation, data warehouses, e-commerce systems, custom applications, and legacy systems at the same time.

Middleware and iPaaS require more upfront architecture, but they reduce long-term integration sprawl when governance and reuse matter.

16. Synchronous Integration

Synchronous integration is used when a user or system needs an immediate response.

For example, a Salesforce user may need to check real-time inventory, validate customer information, or retrieve current pricing from another system. REST API and SOAP API can support these request-reply or remote call-in patterns.

The key concern is latency. A synchronous integration must account for API entitlements, backend response time, field-level security, object permissions, and meaningful error messages for users.

17. Asynchronous and Event-Driven Integration

Asynchronous integration is better when the process does not need to complete immediately in front of a user.

Salesforce Change Data Capture and Platform Events are important for event-driven architecture. Salesforce stores platform events and CDC events for 72 hours, with replay support during that retention window. That makes them useful for near-real-time data propagation and recovery after short disconnections.

However, CDC and Platform Events are not a full enterprise message bus replacement. For long-term retention, guaranteed replay, deep reprocessing, or large fan-out requirements, businesses often need an additional broker, lakehouse, iPaaS, or event-streaming layer around Salesforce events.

18. Batch Integration, ETL, ELT, and CDC

Batch integration is useful for large-volume data movement, analytics, migration, periodic synchronization, and high-volume ingestion.

Bulk API 2.0 is the standard choice for high-volume Salesforce ingestion and querying, but it processes in parallel, which can increase the possibility of lock contention and out-of-order effects.

That is why volume, transaction behavior, object relationships, and locking risks need to be considered before choosing a batch or bulk integration design.

Data Modeling: Where Salesforce Integrations Often Win or Fail

Many Salesforce integration failures are really data design failures.

Salesforce objects such as Account, Contact, Opportunity, and Case may work as canonical anchors, but external systems rarely share the same IDs, picklist values, lifecycle stages, or relationship structures.

Common data modeling problems include duplicate customer records, person-account mismatches, inconsistent status values, ERP line-item structures that do not match Salesforce opportunity structures, unclear source-of-truth ownership, and weak master data management.

This is why external IDs, upsert logic, external lookups, indirect lookups, deduplication, MDM, data governance, and data quality rules are so important.

A Salesforce integration can be technically functional and still create business confusion if the data model is not designed properly.

Salesforce Integration Capabilities

So the first thing we should be talking about here is Capabilities vs Architecture vs Patterns. All three are different from one another. So while we’re at it, it’s important for us to make that distinction clearly because usually you see these terms being used very interchangeably during Salesforce integration conversations. But believe me you, all three are very different aspects of Salesforce integration.

Architectures define the overall structure of how systems are connected.

1. Point-to-Point.
2. Hub-and-Spoke.
3. Event-driven architectures.

Patterns describe the common ways information flows between systems.

1. Request and reply.
2. Fire and forget.
3. Batch synchronization.

Capabilities are the ACTUAL technologies + tools that Salesforce provides to IMPLEMENT THOSE VERY PATTERNS AND ARCHITECTURES.

1. Rest API
2. Bulk API
3. Streaming API
4. Salesforce Connect
5. Outbound Messages

So, even though it may be obvious, but while we’re at it, let’s not cut corners. Why do capabilities matter in Salesforce integration?

So let’s say you have an idea of a complete flow, that you’re going to integrate this and implement that and achieve a particular goal. 

Now’s the time to implement your idea using Salesforce. The question is, can you implement it? Or rather, do you have the necessary resources to implement your idea?

That’s where the Salesforce capabilities come into play because that’s how you’re going to bring your idea to life. Salesforce capabilities provide all the building blocks that you’ll need to allow systems to exchange information, automate processes, and to operate at scale.

That’s exactly why capabilities matter when it comes to Salesforce Integration – and that is exactly why it’s important for you to understand capabilities as well. You’re always one wrong move away from causing unnecessary complexity, or even worse, performance bottlenecks and scalability issues.

Will expand more on the horrors when we go to the challenges section because I have testimonies. The good ones, the bad ones, the ugly ones, and funny ones.

Given that you’ve now understood capabilities vs patterns vs architectures – we’ll now discuss:

1. Rest API
2. SOAP API
3. Bulk API
4. Streaming API
5. Outbound Messages
6. APEX Callouts
7. Salesforce Connect
8. Heroku Connect

Rest API

Representational State Transfer Application Programming Interface.

LOL. I feel like I’m saying Myocardial Infarction instead of simply saying “A Heart Attack”. 

But don’t worry, I’ll break this down in 4 points.

1. You’re integrating Salesforce with an or multiple external applications.
2. To do that, you’ll need a REST API.
3. That’s one of the most common uses of REST API.
4. It basically allows different systems to exchange information using standard HTTP methods.

So, how does the REST API Work?

REST API allows/enables systems to send requests to Salesforce to:

1. Create Records
2. Retrieve Records
3. Update Records
4. Delete Records

Data is usually exchanged in JSON format. That way, REST stays lightweight and easy to consume.

Primary HTTP Methods (or API Operations) Used By REST APIs To Interact With Data And Records.

1. GET: Retrieves data.
2. POST: Creates records.
3. PUT/PATCH: Updates records.
4. DELETE: Removes records.

Common Use Cases

REST API is commonly used for:

• Web and mobile applications.
• Salesforce and ecommerce integrations.
• CRM and marketing platform integrations.
• Real-time data synchronization.
• Custom application development.

Advantages and Limitations

Advantages

• Lightweight and fast.
• Uses JSON format.
• Easy to implement.
• Highly scalable.
• Widely supported.

Limitations

• Synchronous by nature.
• Subject to API limits.
• Less suitable for large-volume data loads.
• Requires authentication and security management.

SOAP API

Okay So SOAP API is older and has more specialized use cases. So when we’re talking about it, we’ll shift our focus more towards when it should be used, why some legacy and enterprise systems still rely on it despite it being older and having more specialized use cases, and how it differs from REST.

SOAP, or Simple Object Access Protocol, is a Salesforce integration capability that was designed for system-to-system communication. 

So, naturally the next question is how it exchanges data? It uses XML and relies on strict contracts such as WSDL files to maintain consistency between applications.

When SOAP is Actually Preferred?

Although REST API is more popular today, SOAP API is still widely used in enterprise environments and legacy systems.

SOAP API is commonly preferred when:

• Formal contracts between systems are required.
• High reliability and security are critical.
• Integrating with older enterprise applications.
• Complex system-to-system communication is involved.
• XML-based messaging is already in use.

Strengths and Weaknesses

Strengths

• Highly reliable and secure.
• Supports strict data contracts.
• Well-suited for enterprise integrations.
• Excellent for backend system communication.

Weaknesses

• Uses XML, which is heavier than JSON.
• Consumes more bandwidth.
• More complex to implement.
• Generally slower than REST API.

BULK API

Bulk API solves a fundamentally different problem.

REST and SOAP APIs are more of a general-purpose integration of Salesforce capabilities.

They are used for everyday communication between systems.

But when it comes to Bulk API – they are designed specifically for high-volume data processing and asynchronous operations. So naturally, it processes massive amounts of data efficiently. It can process up to 100 million records within a rolling 24-hour period. Absolutely ideal for enterprise-scale data operations.

So the main questions we should be asking here are: How much data it can handle, and why it is preferred for large-scale migrations, and batch processing.

Bulk API 1.0 vs Bulk API 2.0

Bulk API 1.0

• Supports parallel and serial processing.
• Requires manual batch management.
• Provides greater control over jobs.

Bulk API 2.0

• Automatically manages batching.
• Simpler to configure and use.
• Optimized for large data loads.
• Recommended for most modern implementations.

Data Migration and ETL Use Cases

Bulk API is commonly used for:

• Initial Salesforce data migrations.
• Loading millions of records.
• ETL and ELT processes.
• Data warehouse synchronization.
• Periodic batch updates.
• Large-scale imports and exports.

Because Bulk API processes records asynchronously, users can submit jobs and continue working while Salesforce handles the data in the background.

Streaming API

Streaming API addresses an entirely different integration requirement.

Bulk API is all about moving huge amounts of data efficiently. On the other hand, Streaming API focuses on enabling near real-time event-driven communication.

So here, we’re less concerned with versions or data migration and more interested in understanding the publish-subscribe model, the different event types available and how streaming API enables systems to react immediately to changes.

Basically, it all boils down to the business problem that Streaming API solves. It’s fundamentally different from the problems solved by REST, SOAP, or Bulk APIs.

Publish-Subscribe Model

Instead of continuously requesting data, systems subscribe to events. That way, they only receive notifications whenever changes occur. So there’s no need to continuously request for data. That’s the publish-subscribe model.

Near Real-Time Notifications

Streaming API enables near real-time communication between Salesforce and all the other external systems you have. So as soon as the event occurs, subscribed applications are automatically notified.

PushTopic Events

PushTopic Events notify subscribers when records matching specific SOQL query criteria are created, updated, or deleted.

• Query-based notifications.
• Near real-time updates.
• Common in custom applications.

Platform Events

Platform Events allow Salesforce and external systems to publish and consume custom events.

• Event-driven integrations.
• Loose coupling between systems.
• Supports asynchronous communication.
• Widely used in enterprise architectures.

Change Data Capture

Change Data Capture (CDC) automatically publishes events whenever Salesforce records change.

• Tracks create, update, delete, and undelete operations.
• Eliminates custom polling.
• Keeps external systems synchronized.
• Ideal for real-time integrations.

Outbound Messages

Outbound messages are much narrower in scope than all the APIs we’ve covered so far.

REST, SOAP, Bulk, and Streaming APIs are very broad Salesforce integration capabilities with multiple applications and implementation considerations.

But when we look at Outbound Messages, they are a very specific Salesforce feature whose main value basically lies in automatically sending messages based on Workflow events.

So as a result, we’ll be focused on how the messages are triggered, how reliability is maintained through acknowledgements and retries, and the scenarios where this capability is useful. We’ll not be primarily focused on the mechanics of the protocol itself.

Workflow-Based Messaging

Outbound Messages allow Salesforce to automatically send messages to external systems whenever a workflow rule or approval process triggers an event.

• Declarative and no-code.
• Sends selected fields to a specified endpoint.
• Based on SOAP messaging.
• Operates asynchronously.

Acknowledgement and Retries

After receiving an outbound message, the external system sends an acknowledgement back to Salesforce.

• Confirms successful delivery.
• Salesforce automatically retries failed deliveries.
• Retries continue for up to 24 hours.
• Administrators are notified if delivery ultimately fails.

Typical Use Cases

Outbound Messages are commonly used for:

• Workflow-based notifications.
• Updating external systems.
• Approval process integrations.
• One-way asynchronous communication.
• Legacy SOAP-based integrations.

Apex Callouts

Making Requests From Salesforce

Apex Callouts are one of the Salesforce capabilities used in Salesforce integration to allow Salesforce to send requests to external systems and receive responses.

• Programmatic and developer-driven.
• Supports REST and SOAP services.
• Enables real-time communication.

Synchronous vs Asynchronous Callouts

Synchronous Callouts

• Salesforce waits for a response.
• Best for immediate processing.

Asynchronous Callouts

• Processing continues without waiting.
• Suitable for long-running operations.
• Helps avoid timeouts.

Integration Scenarios

Apex Callouts are commonly used in Salesforce integration for:

• Address verification.
• Payment gateway integrations.
• ERP and inventory systems.
• Third-party web services.
• Custom business processes.

Salesforce Connect

Data Virtualization

Salesforce Connect is one of the Salesforce capabilities used in Salesforce integration to access external data without storing or duplicating it inside Salesforce.

• Real-time data access.
• Reduces storage requirements.
• Maintains a single source of truth.

External Objects

Salesforce Connect uses External Objects to represent data stored in external systems.

• Behave similarly to custom objects.
• Support reports and related lists.
• Enable access to external records.

Real-Time Access Without Replication

Data remains in the source system and is retrieved only when needed.

• No data duplication.
• Always displays the latest information.
• Ideal for large datasets and ERP integrations.

Heroku Connect

Salesforce ↔ PostgreSQL Synchronization

Heroku Connect is one of the Salesforce capabilities used in Salesforce integration to synchronize data between Salesforce and PostgreSQL databases.

• Supports bi-directional synchronization.
• Keeps Salesforce and Postgres data aligned.
• Built for cloud-native applications.

High-Volume Applications

Heroku Connect is designed for applications that generate massive amounts of data.

• Handles millions of records.
• Supports large-scale workloads.
• Ideal for customer-facing applications.

Low Latency and High Throughput

Heroku Connect enables fast and efficient data exchange between systems.

• Near real-time synchronization.
• Low latency performance.
• High throughput processing.
• Suitable for enterprise-scale environments.

Monitoring, Error Handling, and Observability

Salesforce integration does not end after deployment.

A production-ready integration needs monitoring, alerting, logging, retry handling, and operational visibility.

Salesforce Event Monitoring exposes logs through the EventLogFile object and APIs. API usage tools expose daily and monthly entitlement consumption. A strong integration design should include correlation IDs, structured payload logging, error classification, retry rules, dead-letter handling for async flows, API usage dashboards, and alerts for authentication or token anomalies.

This is what separates a working integration from a reliable integration.

A working integration moves data.

A reliable integration tells you when something failed, why it failed, whether it can retry safely, and who needs to act.

Salesforce Integration Best Practices

The best Salesforce integration strategy starts before any connector is configured.

First, decide which data should live in Salesforce and which data should stay external. Unnecessary replication can create data quality problems, governance issues, storage overhead, and sync complexity. Virtualization through Salesforce Connect may be a better fit when users need access to external data without copying everything into Salesforce.

Second, define the system of record for every major entity: customer, account, contact, product, pricing, order, invoice, case, consent, and finance data.

Third, assign external IDs early. External IDs and idempotent upserts help prevent duplicates when records are updated repeatedly or retried after failures.

Fourth, choose the right integration pattern. Use synchronous APIs only when immediate user feedback is required. Use asynchronous events, CDC, ETL, ELT, or batch sync when instant response is not necessary.

Fifth, design security and observability from day one. OAuth scopes, integration users, app approvals, logging, retries, dead-letter handling, API dashboards, and alerting should be part of the initial architecture, not final-stage cleanup.

Salesforce Integration Checklist

Before starting a Salesforce integration project, answer these questions:

1. Which business processes need cross-system data or actions?
2. Which system is the source of truth for each major data object?
3. Does the use case need real-time sync, near-real-time events, batch sync, or virtualization?
4. Are external IDs, dedupe rules, relationship mappings, and lifecycle definitions ready?
5. Which APIs or integration patterns fit the use case: REST, SOAP, Bulk API, Composite API, CDC, Platform Events, Pub/Sub API, ETL, iPaaS, ESB, or Salesforce Connect?
6. How will OAuth scopes, integration users, app approvals, and token governance be controlled?
7. How will API usage, failures, retries, and dead-letter events be monitored?
8. Does the team have Salesforce architects, admins, API developers, data architects, security engineers, QA testers, performance testers, and operations support?
9. Should the business use native Salesforce tools, MuleSoft, Boomi, Informatica, Workato, custom code, or a hybrid architecture?

How to Choose the Right Salesforce Integration Approach

The right Salesforce integration approach depends on the size and complexity of the business.

Native Salesforce tools may be enough for narrow Salesforce-centric integrations. MuleSoft is stronger when API-led connectivity, reuse, governance, and hybrid integration matter. Boomi and Workato are useful when low-code integration and automation speed are priorities. Informatica is strong when data governance, CDC, MDM, quality, and AI-ready data architecture matter. Custom code fits edge cases but increases long-term maintenance responsibility.

A simple way to think about it:

Do not choose the tool only because it is fast to configure.

Choose the architecture based on business process complexity, data ownership, latency needs, transaction volume, API limits, security requirements, governance maturity, and long-term support.