Picking the right Salesforce integration options
When you start looking at Salesforce integration options, the sheer number of tools makes it easy to freeze up. I've been in plenty of design sessions where the team burned hours arguing over whether to use a middleware tool or just write some custom Apex. Most teams go wrong by over-engineering a simple connection, or by forcing a low-code tool to do something it was never built for.
Knowing what the tools do is the easy half. Knowing which pattern fits your problem is the half that decides the design. Are you moving millions of rows? Do you need a response in under a second? Or are you just sending a notification when a deal closes?
Common patterns for Salesforce integration options
Before the specific tech, the patterns. They describe how the data moves, and they narrow the tool list fast.
- Request and reply: the classic synchronous call. You ask for something and wait for the answer. A REST callout to get a credit score.
- Fire and forget: you send a message and move on with your life. No response, no waiting. Outbound Messages and Platform Events live here.
- Batch data sync: the heavy lifting. If you're syncing nightly sales data, you're in batch territory.
- Data virtualization: the look but don't touch approach. You show data in Salesforce without storing it there.
Pro tip: Always start by asking about the data volume and the required "freshness." If the business says they need it in real-time, ask them why. Half the time, a five-minute delay is perfectly fine and saves you a ton of dev work.
Comparing popular Salesforce integration options
1. REST and SOAP APIs
REST is the bread and butter of modern integrations: lightweight, JSON, and what almost every modern web service expects. Don't count SOAP out, though. Some older enterprise systems still want a formal WSDL and strict contracts. If you're stuck choosing, I've written a breakdown on Salesforce SOAP vs REST that goes deeper into the why behind each one.
2. Bulk API 2.0
If you're moving more than 100,000 records, stop looking at the standard REST API. You'll hit limits faster than you can blink. The Bulk API is built for managing large data volumes and processes data in the background, so it won't hang up your user interface.
3. Change Data Capture (CDC) and Platform Events
I'm a huge fan of event-driven architecture. CDC publishes an event whenever a record changes, with no code from you. Platform Events give you more control, since you define your own schema and publish from Flow or Apex whenever you want. Either way you decouple your systems, so one of them going down doesn't bring the whole house down with it.
4. Outbound Messages
This is one of the oldest Salesforce integration options, and it still works. It's declarative, so you can set it up in a Flow without code, and it sends a SOAP message to an external service. It retries automatically if the endpoint is down. It's also clunky, because it only speaks XML.
5. External Services
Underrated, especially for the low-code crowd. If you have an API with an OpenAPI (Swagger) definition, you can register it in Salesforce and call it straight from a Flow, no Apex callouts needed. Perfect for citizen developers who need to connect to an external system without owning a codebase.
Custom code vs. middleware
So when do you stop using the built-in tools and start looking at Apex or middleware?
Apex callouts and custom endpoints
Sometimes you just need custom logic. Maybe the data has to be transformed in a very specific way before it goes out. That's where HttpRequest and Http come in. Always use Named Credentials here. It keeps your auth secure and makes juggling sandbox and production much easier.
// A quick example of a clean Apex callout
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:MyExternalSystem/v1/sync');
req.setMethod('POST');
req.setBody('{"status": "active"}');
Http http = new Http();
HTTPResponse res = http.send(req);
Middleware and iPaaS
If you're connecting Salesforce to ten different systems, don't build ten custom integrations. That's a maintenance nightmare. Use something like MuleSoft or Boomi. These platforms handle the retries, the mapping and the monitoring, so you don't end up building a custom logging framework inside Salesforce.
How to decide which option to use
So how do you actually pick? I usually run through a quick mental checklist:
- Is it a lot of data? Use Bulk API.
- Does it need to be declarative? Use Outbound Messages or External Services.
- Is it a simple UI update? Use the standard REST API.
- Do we need to show data without storing it? Use Salesforce Connect.
- Is the logic super complex? Use Apex callouts.
Key takeaways for Salesforce integration options
- Favor declarative tools like Flow and External Services first.
- Use Named Credentials for every single callout to keep your secrets safe.
- Don't ignore the Bulk API once you're past a few thousand records.
- Event-driven designs (CDC and Platform Events) are usually more reliable than tight synchronous coupling.
- Middleware earns its cost once you have more integrations than you can keep straight.
The best integration is the one you don't have to fix every Tuesday morning. Start simple, stay declarative as long as you can, and break out the custom code only when you have to.
Leave a Comment