Getting Real with Salesforce Integration Patterns
If you’re prepping for a technical interview soon, you’ve likely realized that Salesforce integration patterns are the bread and butter of any senior-level conversation. It’s one thing to know how to build a flow, but it’s another thing entirely to explain how Salesforce should talk to an external ERP without hitting a wall. I’ve sat on both sides of the interview table, and the candidates who stand out are the ones who don’t just memorize the names of the patterns, but actually understand the trade-offs.
Look, there isn’t a one-size-fits-all solution here. Every project has different needs for speed, data volume, and security. Let’s break down the core patterns you’ll actually use in the field and what you should say when an interviewer puts you on the spot.
1. Remote Call-In (The “Call Me” Pattern)
This is where an external system reaches out to Salesforce to get something done. I’ve seen this used most often when a company has a custom web portal that needs to validate an order or look up a customer record in real-time. It’s a synchronous request, meaning the external system is waiting right there for an answer.
The pros? It’s fast and ensures your business logic stays inside Salesforce. The downside is that you’re now tightly coupled. If Salesforce is down for maintenance, your portal is basically broken. When you’re designing for a Salesforce API integration, you’ll usually handle this with a custom Apex REST controller.
@RestResource(urlMapping='/OrderValidate/*')
global with sharing class OrderValidate {
@HttpPost
global static String validate() {
// parse the request and run your logic
return 'OK';
}
}2. Remote Process Invocation-Request and Reply
This is the opposite of the first pattern. Here, Salesforce is the one making the call. You’re in the middle of a process – maybe an Opportunity is being closed – and you need to hit an external service to get a credit score before you can finish.
It’s great because Salesforce stays in the driver’s seat. But here’s the thing: blocking callouts consume transaction time. If that external service takes five seconds to respond, your user is staring at a loading spinner for five seconds. In modern Lightning UI, you’ll want to use “continuation” to keep things from freezing up.
3. Batch Data Synchronization
Now, if you’re dealing with large data volumes, you don’t want to use real-time calls. That’s a quick way to hit your limits. Instead, you go with batch sync. This is your classic nightly ETL (Extract, Transform, Load) job.
I’ve worked on projects where we moved millions of rows from a legacy SQL database into Salesforce every weekend. It’s efficient and doesn’t eat up your real-time API limits, but the obvious catch is data latency. Your data is only as fresh as the last sync. If the business needs to see “live” inventory, this isn’t your winner.
4. Remote Process Invocation-Fire and Forget
This is my personal favorite for keeping an org snappy. Salesforce sends a message to another system but doesn’t wait around for a reply. It’s like sending a text message and putting your phone away. You know it’ll get there, but you’ve got other things to do.
You’ll usually see this implemented with Platform Events or Outbound Messaging. If you’re torn between the two, check out this guide on Platform Events vs Outbound Messages. It’s a solid way to offload heavy processing to a middleware tool like MuleSoft or Boomi.
5. Data Virtualization
Sometimes, the best way to integrate data is to not move it at all. Why store 10 million rows of historical shipping data in Salesforce when you can just look it up on demand? This is where Salesforce Connect and External Objects come in. You’re basically creating a window into another database. It’s great for keeping your storage costs down, but it relies heavily on the external system’s performance. If their database is slow, your Salesforce page is slow.
Choosing Between Salesforce Integration Patterns
So, how do you actually pick one? When an interviewer asks “Which pattern would you use?”, they’re looking for your thought process. Here’s how I usually frame it. First, I look at the timing. Does the user need an answer in under a second? If yes, you’re looking at a synchronous pattern. If not, go async every time to save your governor limits.
Second, think about where the data lives. If Salesforce doesn’t need to “own” the data for reporting or searching, virtualization is a strong candidate. But if you need to run complex SOQL queries against that data, you’ll have to bring it into the platform via batch or real-time sync.
One thing that trips people up is error handling. In a synchronous call, you get an error code immediately. In an asynchronous “fire and forget” setup, you need a strategy to catch failures later, or that data just disappears into the void.
6. UI Integration
We shouldn’t forget about the UI side of things. Sometimes you don’t need to sync data at all; you just need to show a legacy system’s screen inside Salesforce. I’ve used Canvas apps for this when we had a complex home-grown pricing tool that was too hard to rebuild in LWC. It’s a quick win for user experience, but you have to be careful with session management and single sign-on (SSO).
7. Event-Driven Architecture
This is where the ecosystem is heading. Instead of point-to-point connections, you have systems publishing events to a bus. Salesforce might publish an “Account Updated” event, and three different systems (Marketing, ERP, and Analytics) all subscribe to that event and react. It’s the ultimate way to decouple systems. It’s more complex to set up, but it’s way easier to maintain as the company grows.
Key Takeaways for Your Interview
- Synchronous is for when you need an immediate answer, but it’s risky if the other system is slow.
- Asynchronous (Fire and Forget) is the gold standard for reliability and user experience.
- Batch is for the heavy lifting of millions of records where “real-time” doesn’t matter.
- Virtualization saves you on storage but costs you in query performance.
- Middleware is your friend. Don’t try to build complex transformation logic inside Apex if you have a tool like MuleSoft available.
Wrapping Up
Understanding Salesforce integration patterns isn’t about memorizing a textbook. It’s about knowing which tool to pull out of your belt when a specific problem hits your desk. When you’re in that interview, talk about the “why” behind your choice. Mention the limits you’re trying to avoid and the user experience you’re trying to protect. That’s what a real architect does.
If you’ve got a weird integration scenario you’re struggling with, or if you’ve seen a pattern used in a way I didn’t mention here, let’s talk about it. Most of what I’ve learned came from breaking things in a sandbox first, so don’t be afraid to experiment with these different approaches.