The Systems Around Salesforce

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 3 of 6 in the chapter Understanding Enterprise Data, chapter 4 of the Data Architect course. Each module stands on its own. Previous: The Kinds of Enterprise Data · Next: Draw the System Landscape

The question this module answers: What surrounds Salesforce, and what role does each system play?

The last module sorted the data. Now I want to put it somewhere, and this is where Salesforce architects get into trouble. We know Salesforce, so customer data means Account, order data means Order, documents mean Files, analytics means Reports. But the enterprise didn’t buy Salesforce to replace everything else it owns. There may be an ERP running finance and fulfillment, a warehouse with years of history, an integration platform, an identity provider, partner systems, an event platform, an MDM platform, and Data 360 connecting several of them. The job isn’t memorizing technologies. It’s understanding what job each system has.

Don’t Start With the Product Name

“We have SAP” doesn’t tell me enough. Neither does Snowflake, MuleSoft, Tableau or Data 360. I want to know what that system does in this architecture: what data it owns, what it reads, what it changes, who uses it, what depends on it, what happens when it’s down. Two companies can own exactly the same products and have completely different architectures.

So I label systems by role. Four roles cover most of it:

• System of record: where the authoritative version of something is maintained.
• System of engagement: where people do the work.
• System of reference: where a system goes for information it needs but doesn’t own.
• System of insight: where data comes together to measure, analyze and predict.

One platform can play several roles, and the roles differ by data. Salesforce may be the system of record for cases, the system of engagement for service agents, and a consumer of product data the ERP owns. So when someone says “Salesforce is our system of record,” finish the sentence: system of record for what?

The ERP: the Back Office Has Gravity

The ERP is the system you’ll find next to Salesforce most often, running finance, inventory, purchasing, fulfillment and billing. Module 1’s pattern (customers and products in, orders out) means the ERP owns the products, but salespeople still need them in Salesforce. Fine: bring them in. But copying data doesn’t transfer ownership. A copy is not authority.

My position: ERP-owned data is read locally and written under control. Salesforce users get the data where they work, but Salesforce doesn’t get to change what the ERP owns. And I make that visible in the schema: the ERP’s fields carry an erp_ prefix, like erp_Product_Number__c, so anyone reading the object knows who owns each field and to be careful changing it. The prefix doesn’t enforce anything; permissions, validation and the integration pattern do that. It communicates intent, and it’s the authority map made visible.

The Warehouse, the Lake and the Lakehouse

Operational systems run the business; analytical systems help understand it. “Show me my open opportunities” is a Salesforce report. “Show me five years of sales, fulfillment, returns, cases, inventory and finance across every channel” is a different problem.

You’ll meet three kinds of analytical store. A data warehouse holds structured data prepared for analysis. A data lake holds far more data in more forms, often raw. A lakehouse combines the two: lake-style storage with warehouse-style analysis. Know them, because they show up on landscapes. But my experience is that lakehouses and data mesh are still niche on Salesforce projects. The typical landscape is CRM, ERP, a warehouse and an integration layer, with other platforms where the business genuinely needs them. Learn the architecture; don’t chase the vocabulary.

Analytics Lives Where the Data Lives

This is one of my firmest positions: where analytics lives follows where the data lives. If the report only needs accounts, opportunities and salespeople, it’s all on core: standard reports and dashboards. Then the business asks to add ERP invoices. Then product cost. Then five years of orders from the warehouse. Then website activity. At some point, dragging all of that into the operational CRM just to report on it stops making sense. Once other data stores are involved, an analytics platform becomes necessary: Tableau (including Tableau Next, built on Data 360), or CRM Analytics where it’s already in use. It’s essential when Salesforce data is merged with a warehouse. The requirement didn’t just get more complicated; the landscape changed where the question should be answered. So I never start with “which analytics tool?” I start with where is the data?

I ask CTA candidates the same thing: “Which of my diagrams solves this beautifully? Landscape.” If you’re all on core, use reports. If you have data in other repositories, I want to see an analytics platform. The landscape answers the reporting question before anyone opens a report builder. (The product names change; the Data 360 chapter covers where Salesforce’s analytics stands today.)

MDM: Who Is This Customer, Really?

Now suppose customer information lives in Salesforce, the ERP, e-commerce, a loyalty platform and a partner system, and each one thinks it knows who the customer is. That’s where master data management comes in: establishing and governing the authoritative identity of key data across systems. But MDM isn’t “a master customer database.” The hard questions are which system may create the customer, which attributes each system owns, how duplicates are found, which identifier survives, and what happens when systems disagree. Chapter 6 is all about that. Here, recognize the role: if an MDM platform exists, it may be a critical authority between Salesforce and the rest of the enterprise.

The Integration Layer and the Events

Connect every system directly to every other, and the landscape turns into spaghetti fast. That’s why enterprises have an integration layer: an ESB (enterprise service bus) or iPaaS (integration platform as a service). MuleSoft is the one you’ll meet most in Salesforce landscapes. It mediates, so each application doesn’t have to understand every other one.

But a MuleSoft box in the middle doesn’t make the integration good. I still want to know what goes through it and what doesn’t, who transforms the data, who owns the contract, what happens when the destination is down, whether it’s synchronous or asynchronous, and how we know a message succeeded. The Integration Architect course goes deep; here, recognize it as its own role.

And not every integration is system A calling system B. Sometimes something happens (an order is created, a delivery changes status, a truck crosses into a region), an event is published, and whoever’s interested responds. Events in motion have infrastructure too: Salesforce’s own event capabilities, an enterprise event bus, other messaging. Draw the mechanisms that carry the data, not only the databases.

The System Developers Forget: Identity

There’s one box I always want on the landscape that developers rarely think about: the identity provider. Developers log straight into their sandboxes with a username and password, so identity is invisible during the build. Then UAT or production arrives, and suddenly there’s the company’s single sign-on for employees, maybe a second provider for partners, social sign-on for customers. Identity was always part of the architecture. The developer just didn’t see it yet.

An identity provider (IdP) is the system that authenticates a user and establishes the identity Salesforce trusts. It belongs on the landscape from day one, even if it’s configured later in the release pipeline, because who can get in decides who can get to the data.

There’s a practical wrinkle, too: identity configuration is deployable, but not completely. SAML single sign-on configuration and authentication providers are Metadata API types, so they travel through the pipeline (SamlSsoConfig (opens in a new tab)). But authentication-provider consumer secrets are no longer returned in Metadata API responses (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), and certificates usually differ by environment. Plan for the parts that travel and the parts that don’t.

Click to enlarge

Read the landscape as roles, not logos: what each system owns, reads, or decides.

Where Does Data 360 Sit?

Data 360 raises a nice drawing question. I put it to the right, below the ESB or MuleSoft. The reason is its connections: users never connect to it directly, while it connects directly to many back-end systems. So it belongs with the data plumbing, where those lines stay short, not out with the users. Draw it like another screen people log into, and you’re telling the wrong story.

Admins and data teams do open Data 360’s screens, but those screens are in the org, on core. The tenant doing the work, its data and its processing, runs off core. That’s why I call it near-core: managed on core, hosted off core (module 1 explains the terms). The drawing follows the tenant: it sits with the plumbing, with one line back to the org that manages it.

What it does, in Salesforce’s words, includes zero copy: a data federation technology that lets an enterprise access and query data without copying it (Zero Copy (opens in a new tab)). The capabilities and connectors change quickly, so the Data 360 chapter covers them properly rather than turning this module into a product tour.

Read the Landscape as Responsibilities

When you look at a landscape, don’t read the logos; read the responsibilities. The ERP: what does it own? The warehouse: what questions does it answer? The integration platform: what does it move? The IdP: whom does it authenticate? MDM: what identity does it govern? Data 360: what does it connect, and for what? Salesforce: what is it actually responsible for? Once you can answer those, the boxes mean something, and the arrows between them get much more interesting. Next, we draw them deliberately.

What an Architect Decides Here

• What role each system plays, beyond its product name.
• Which system is authoritative for each important data set, and where Salesforce holds only a local copy.
• Whether ERP-owned data is available in Salesforce with writes controlled, and how that ownership shows in the schema.
• Where analytics belongs, based on where the data lives.
• Where identity, integration, events and master-data authority sit on the landscape.

A landscape with ten rectangles isn’t architecture; it’s inventory. Architecture starts when you can point at every rectangle and say why it’s there, what it owns, who uses it, what Salesforce needs from it, and what breaks if you misunderstand its role.

Explore

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab), checked 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab) (product page), checked 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019.