Introduction

In any enterprise, Salesforce rarely stands alone – it must connect with a web of other systems to deliver a unified customer experience. Yet integrating systems is hard: data silos, inconsistent records, slow updates, and security gaps can derail even the best project.

"When systems don't talk, your business can't listen."

A structured Integration Decision Making Framework helps architects avoid these pitfalls. Instead of building one-off connections ad hoc (which often creates a fragile web), the framework provides a systematic way to evaluate integration options. It ensures key factors are considered up front. In essence, the framework centers on key considerations and prompts questions like Data or process integration? Real-time or batch? This way, you choose an approach based on reasoning, not guesswork.

That’s why I’ve created an eight-part series on the Salesforce Integration Decision Making Framework. Think of it as your map and compass in the wilderness of data flows, APIs, security considerations, and real-world constraints.

What to Expect in This 8-Part Series

‍

The Integration Decision Making Framework: A Quick Overview

Picture your architecture as a  city of systems: Salesforce might be your town square, an ERP the business district, and third-party apps the local shops. The roads (integrations) connecting them must handle high traffic safely, reliably, and quickly.

At its core, the framework answers questions like:

• Which data belongs in Salesforce vs. stays outside?
• Do we integrate in real-time or batched intervals?
• Is the communication synchronous (pause for a reply) or asynchronous (fire and forget)?
• What about security, scaling, and compliance?

The best part? You don’t have to guess. By following these structured steps, you’ll avoid massive rework later.

The Integration Path

“Integration decisions become easier once you know who’s the boss: the System of Record or the System of Engagement.”

Example: Retail Loyalty Program Integration

Consider a company integrating a retail loyalty program system with Salesforce. Salesforce is used for customer service, while a separate loyalty application manages the program’s data. Using the framework, you can decide the followings:

• Integration approach: Don’t replicate the entire loyalty database into Salesforce. Instead, Salesforce will fetch loyalty point balances on demand from the external loyalty system.
• Communication style: When a purchase triggers points to be added, Salesforce sends an asynchronous request to the loyalty system so checkout isn’t slowed; when a service agent needs to check a customer’s points in Salesforce, a synchronous call fetches the latest value immediately. This way, transactions stay quick while agents get real-time info when they need it.
• Source of truth: The loyalty system remains the system of record for loyalty data. Salesforce displays it but never overwrites it. Any point adjustments initiated in Salesforce are performed via the loyalty system’s API, and all data transfers use HTTPS and OAuth for security.

This example shows the framework in action – guiding what data to replicate (very little), how to handle timing (real-time vs. batch), how to communicate (async vs. sync), and who owns the data (loyalty system as SOR). The result is that users get up-to-date loyalty info without unnecessary complexity or risk.