Salesforce Integration — My Learning Journey

Rayan — Tue, 06 Oct 2026 19:49:56 +0000

We're going to go to some extent into general integration concepts in the second post of this series.

I think it will be a good prerequisite on our road to Salesforce Integration.

Integration is the process of connecting systems, regardless of how many systems are involved.

Generally, there are two common architectural approaches:

i) Point-to-Point (coupled)

ii) Mediated (decoupled)

Although both achieve the same goal, they help us achieve it in different ways, with their own benefits and trade-offs.

Point-to-Point

Point-to-point helps connect two systems directly, without anything between them acting as a mediator or broker.

The communication can be implemented using different technologies or approaches such as REST, SOAP, RPC, and others. But the important point here is that the systems are directly connected, which can create tight coupling between them.

For example, assume Salesforce needs data from an ERP to process an order and move it to the next step.

Salesforce and the ERP need to communicate with each other. They could communicate through an API exposed by the ERP, such as a REST or SOAP API.

But here Salesforce has a direct dependency on the ERP's interface. If something changes in the ERP's exposed API — for example, its authentication process changes, the payload format changes, or a new API version is introduced — Salesforce may also need to be changed to work with the new interface.

This is what tightly coupled means here: changes in one system can directly affect the integration logic of another system.

This is just an example to understand the concept easily and doesn't mean that Salesforce and other systems are always integrated this way.

To reduce this kind of direct dependency, mediated integration comes in.

Mediated Integration

Mediated integration is another approach where the systems communicate through an interface or intermediary between them.

This intermediary acts as a mediator for communication between the systems.

This can be broadly differentiated into two approaches:

i) Simple Broker

ii) Orchestrator

Simple Broker

A simple broker mainly acts as an intermediary for routing or delivering messages. It doesn't become part of the actual business process or decide the sequence of business operations.

For example, suppose Salesforce wants some data from SAP.

Instead of Salesforce directly calling the API exposed by SAP, Salesforce can call an interface exposed by the broker. The broker then communicates with SAP and routes the request to the appropriate system.

If SAP's API changes, the broker can handle the required changes at the integration boundary, while Salesforce can continue communicating with the same interface.

The broker can also support request-reply communication by routing the response back to Salesforce.

The goal here is to reduce the direct dependency between Salesforce and SAP.

Orchestrator

An orchestrator goes a step further by becoming involved in the overall process flow.

For example, suppose Salesforce receives an order.

The orchestrator can coordinate the different steps involved in processing that order:

Communicate with SAP to check product availability for the required region and quantity.
Communicate with the payment gateway to process the payment.
If everything succeeds, continue with the next step of the order process.

Here, the intermediary isn't simply passing messages between systems. It is coordinating the interactions between them as part of the overall business process.

Using this example, I hope you have understood the core basics of integration.

Under these architectural approaches, other integration concepts come into the picture.

For example, request-reply, publish-subscribe, batching, synchronous and asynchronous communication, along with concepts such as inbound and outbound integration and technologies or approaches such as REST, SOAP and RPC.

These concepts describe different aspects of how systems communicate, rather than being different types of point-to-point or mediated architecture.

We'll discuss these in further posts in this series.

And in the next one, I won't disappoint you with more theories and general concepts. It's going to include some Salesforce playarounds.

Stay tuned.

Salesforce and Integration

Rayan — Tue, 29 Sep 2026 18:54:41 +0000

Salesforce Integration — My Learning Journey

This is the first blog I’ve ever written, and I’m planning to document Salesforce Integration along my learning journey through this series.

As I recently started my career in Salesforce, I’ve been curious about integrations. Adding to this, I already have some knowledge of backend technologies, which made me even more interested in understanding how Salesforce communicates with other systems.

Why Salesforce?

Salesforce is a CRM cloud platform that helps organizations manage their customers, data, and business processes.

When I first started learning about Salesforce, I wondered: why couldn’t we just develop our own system or architecture and deploy it on the cloud?

I got the answer to this question after spending some time in my job.

Building a platform like Salesforce from scratch involves much more than just developing the application. Development cost, development time, security, scalability, data integrity, administration, low-code capabilities, and continuous maintenance all have to be considered.

Salesforce, with decades of engineering and experience, provides these capabilities as a platform, allowing organizations to build their solutions on top of it instead of building everything from scratch.

This made me realize that it is not just about whether we can build our own system. We also have to consider the effort and responsibility of building and maintaining everything ourselves when an existing platform already provides these capabilities.

What Made Me Interested in Integration?

This is where my interest in Salesforce Integration started.

Salesforce doesn't always work alone. An organization might use Salesforce to manage customer and sales data, an ERP system to manage inventory, a payment system to process payments, and another system to handle shipping.

For example, when a customer places an order, Salesforce may need to communicate with the ERP to check inventory, with the payment system to process the payment, and with the shipping system to create the shipment.

These systems need to communicate with each other to complete the overall process.

Without integration, these systems would be isolated from each other, and data might have to be transferred manually from one system to another.

What Is Salesforce Integration?

In simple terms, integration is about connecting different systems so they can communicate, exchange data, or trigger actions between each other.

For example, an external application can send a request to Salesforce through an API. Salesforce processes the request and sends a response back to the external application.

Salesforce provides different APIs and integration mechanisms for different requirements. REST API, SOAP API, Apex Callouts, Platform Events, Change Data Capture, and Pub/Sub API are some of the areas I’ll be exploring in this series.

My goal is to understand how these mechanisms work, why they exist, and when each of them should be used.

What's Next?

This is just the beginning of my Salesforce Integration learning journey.

I'll start with the fundamentals and gradually explore APIs, REST, SOAP, Apex Callouts, event-driven integration, authentication, and other integration concepts.

I’m not planning to just memorize what each technology does. I want to understand why it exists, what problem it solves, and when it should be used.

See you in the next one.

DEV Community: Rayan

Salesforce Integration — My Learning Journey

Point-to-Point

Mediated Integration

Simple Broker

Orchestrator

Salesforce and Integration

Salesforce Integration — My Learning Journey

Why Salesforce?

What Made Me Interested in Integration?

What Is Salesforce Integration?

What's Next?