Getting real with Salesforce integration patterns
If you're prepping for a technical interview, you've probably realized that Salesforce integration patterns are the bread and butter of any senior-level conversation. Knowing how to build a flow is one thing. Explaining how Salesforce should talk to an external ERP without hitting a wall is another. I've sat on both sides of the interview table, and the candidates who stand out are the ones who can explain the trade-offs behind each pattern.
There isn't a one-size-fits-all solution here. Every project has different needs for speed, data volume, and security. Below are the core patterns you'll actually use in the field, and what to say when an interviewer puts you on the spot.
1. Remote Call-In (The "Call Me" Pattern)
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. The request is synchronous, so the external system is waiting right there for an answer.
It's fast, and 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 first pattern in reverse. Here, Salesforce is the one making the call. You're in the middle of a process (an Opportunity is being closed, say) and you need to hit an external service to get a credit score before you can finish.
Salesforce stays in the driver's seat, which is the appeal. The catch is that 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
If you're dealing with large data volumes, real-time calls are a quick way to hit your limits. Batch sync is what you want instead: the 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 look it up on demand? This is where Salesforce Connect and External Objects come in. You're creating a window into another database. It keeps your storage costs down, but it leans hard on the external system's performance. If their database is slow, your Salesforce page is slow.
Choosing between Salesforce integration patterns
When an interviewer asks "Which pattern would you use?", they're looking for your thought process. I frame it by timing first. 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
The UI side counts too. 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 decouples everything. It's more complex to set up, and much 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 comes down to 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.
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.
Leave a Comment