Salesforce Is One System Among Many

🌐 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 1 of 6 in the chapter Understanding Enterprise Data, chapter 4 of the Data Architect course. Each module stands on its own. Next: The Kinds of Enterprise Data

The question this module answers: Why does a data architect draw what surrounds the org before designing the org?

When I teach CTA candidates, the homework after the first day is always the same. Read the scenario. Start the system landscape from a blank canvas. Only then take a stab at the data model. Not the objects, not the integrations in detail: the landscape. I want to see what surrounds Salesforce before we decide what belongs inside it.

That’s a change of perspective for a lot of Salesforce professionals. If you’ve spent your career as an admin or a developer, Salesforce is naturally the center of your world. You open Setup, create objects, build flows, write Apex, and integrate other systems into Salesforce. Everything seems to start with the org. An architect has to pull the camera back, because in an enterprise Salesforce is one system among many, and quite often it isn’t the one that owns the data.

Draw the Landscape First

Chapter 2 built the logical model, and chapter 3 asked how it lives on Salesforce. Now I’m going to make the problem bigger. Before deciding what Salesforce should own, I want to understand the enterprise around it. Which systems already exist? Where are customers created, products defined, orders started, invoices generated? Where does identity live? Where does analytics happen, where are documents kept, where does the history sit? Which systems need Salesforce’s data, and which does Salesforce depend on?

Those questions change the architecture. So I start from a blank canvas, put Salesforce in the middle, and draw everything around it. Module 4 shows exactly how I lay it out. For now, the lesson is simply: don’t design the org before you understand the world it has to live in.

Salesforce Is Often Not the System of Record

Take a very common enterprise: Salesforce plus an ERP, an enterprise resource planning system such as SAP or Oracle, that runs finance, products, inventory, purchasing and fulfillment. Now ask a simple question: where does the customer live?

It could be Salesforce, the ERP, or both, and that’s where it gets interesting. Salespeople may work prospects as Accounts in Salesforce, while the ERP issues the official customer number once they become a paying customer. Products and prices? Probably the ERP. Inventory? Almost never Salesforce. Orders might be captured in Salesforce and fulfilled in the ERP; invoices come from the ERP; service lives in Salesforce; analytics is split between Salesforce reports and a warehouse. Suddenly our nice Salesforce data model isn’t the enterprise data model. It’s one part of it.

The Integration I See Over and Over

The most common integration I see goes like this: customers, products and prices flow into Salesforce from the ERP, and orders flow out. Swap in SAP, Oracle or any other ERP; the shape is the same. The ERP owns the golden record for the customer and the product, so those flows come from the right, into Salesforce. Sales closes the deal in Salesforce, so the order starts there and goes back to the ERP to be fulfilled, invoiced and accounted for.

Those flows aren’t just integrations. They tell me where the enterprise believes the truth lives.

One-Way Arrows Make Me Nervous

Whenever I see an integration that only has one flow, I start to get concerned. At the high level, somebody draws a single arrow: orders from Salesforce to the ERP. Fine. Now look deeper. How can I send an order to the ERP if I don’t know its customers, its products or its prices? The order has to be keyed to a customer the ERP already has, and every line has to be a SKU the ERP already sells. I can’t send a line item for a product that doesn’t exist on the other side. So before that order arrow can work, back flows have to exist, running the other way.

That’s the question I ask of every arrow: what does this flow depend on? The high-level arrow you can see usually needs back flows you haven’t drawn yet.

Look deeper still and you find the return journey. Salesforce sends an order. Then what? Was it accepted or rejected? Did it ship, partly ship, get cancelled? Was it invoiced? Does anyone in Salesforce need to know? Maybe they don’t. But somebody should have asked. If nothing comes back, fine. Tell me why.

The Enterprise Didn’t Arrive All at Once

Landscapes get complicated partly because nobody built them all at once. Data has come in waves. Files first: fixed-format records, then delimited files like CSV. Then relational databases for operational data. Then data warehouses to bring it together for analysis. Then NoSQL databases for documents, key-value pairs and graphs that don’t sit neatly in tables. Then data lakes for huge amounts of raw and semi-structured data, and lakehouses that combine the two. Event streams, like Kafka or the Salesforce event bus, move data as it happens instead of in nightly batches. And now federation, where data doesn’t have to be copied into one place before another platform can use it.

The technology isn’t the point yet. This is: the new wave rarely makes the old one disappear. Walk into a large enterprise and you’ll find all of them at once: relational databases, the ERP, Salesforce, a warehouse, a lake, SFTP drops, APIs, event streams, the spreadsheet somebody still emails every Friday, and the one system everyone’s afraid to touch because the person who built it retired six years ago. That’s the enterprise you’re architecting, not the one in the product brochure.

Different Systems Exist for Different Reasons

That’s also why I never start with “how do we get all the data into Salesforce?” Why would I want all of it there? Salesforce may be the best place for sales and service people to work with customers. That doesn’t make it the finance system, the enterprise warehouse, the telemetry store, the document archive, or the home of every click, GPS reading and historical transaction the company has ever produced.

Chapter 3 asked where should this data live? for one org. At the enterprise level, the same question gets bigger: sometimes Salesforce owns the data, sometimes it keeps a copy, sometimes just a reference, and sometimes it shouldn’t have it at all.

Core, Off-Core and Hyperforce

There’s another boundary to understand: even “Salesforce” isn’t one runtime and one database. In chapter 3, on core meant where the data sits: on your desk, in the org’s own objects. Here the same words describe where a product runs. You’ll hear architects use both.

Historically the Core runtime hosted most of the platform. Today Salesforce describes a platform of hundreds of independent, metadata-driven services, with Core remaining the single system of record for application metadata (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). That’s why you’ll hear architects say a capability runs on core or off core.

It mattered long before the platform split into services. When I ask a class why Salesforce bought SteelBrick for quoting rather than Apttus, the answer I’m after is simple: SteelBrick was built 100% on core. Flows and triggers live in core, so a product built there gets the platform’s metadata, customizations and automation with it. That quoting product has since given way to Revenue Cloud, but the lesson hasn’t. Then there’s near-core, and Data 360 is the example I use. Data 360 isn’t core. Its tenant is off core: the data and the mechanisms that process it run in their own lakehouse, beside the org’s relational database rather than inside it (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). But the screens you use to set it up and control it are displayed on core, in the org. So the most precise way I can put it: managed on core, hosted off core. None of the data or processing actually runs in Core; the UI on Core controls the tenant off core. And then, of course, there’s everything off core because it isn’t Salesforce at all.

I care less about memorizing which product runs where this year, because that changes, than about the habit: a boundary can affect data movement, latency, identity, integration and residency. So don’t assume that because a product says Salesforce, its data sits right next to your Account records. Look at the actual architecture.

Then there’s Hyperforce: Salesforce’s infrastructure built for the public cloud and defined as code, rather than its traditional first-party data centers, giving customers more choice over where their data resides (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). That matters, and module 5 comes back to it. But infrastructure architecture isn’t enterprise data architecture. Moving an org to the public cloud doesn’t tell you who owns the customer, where inventory lives, where analytics runs, or which data may cross a border. Hyperforce can shape some of those decisions, especially residency. It doesn’t replace knowing the landscape.

The Landscape Comes Before the Box

So here’s the habit. Someone hands you a scenario. Don’t start building the Salesforce solution. First find the systems: the ERP, the identity provider, the warehouse, the integration platform, partner systems, customer channels, document stores. Then find the data moving between them: customers, products, orders, invoices, documents, events, identities. Then ask who owns each one. Only then decide what belongs in Salesforce. Otherwise you’re designing a box without knowing what it connects to.

Click to enlarge

Step 1 of 3: the org we design, on its own. From here it looks like the whole world.

Click to enlarge

Step 2 of 3: zoom out. Salesforce is one system among many (module 4 teaches this layout).

Click to enlarge

Step 3 of 3: the first arrows. Customers, products and prices in from the ERP, orders out: they say where the enterprise believes the truth lives.

The Landscape Changes the Data Model

This is why it matters to a data architect. Chapter 2 says the customer is an important entity. Fine. Then the landscape says the ERP is authoritative for the customer. That changes the physical model. Salesforce may still keep a local Account, because people use it every day, but now we need the ERP’s identifier as an External ID; we need to know which fields Salesforce may change (I mark the ERP’s fields with an erp_ prefix, as we’ll see in module 3); how quickly ERP changes arrive; whether Salesforce can create a customer before the ERP knows about it; and what happens when the two disagree. Those aren’t integration questions for later. They’re data architecture questions, and the landscape exposed them.

Here’s how one of them bites. A salesperson converts a lead for a big beverage company, creates the Account, wins the deal, and the customer goes over to the ERP. But the company has done business with that beverage company for years, and the ERP already has them. Now there are two. Should the salesperson have been able to create that Account at all? Chapters 5 and 6 come back to it; the landscape is where you see it coming.

What an Architect Decides Here

• Which systems surround Salesforce, and what role each one plays.
• Which system owns each important kind of data, before deciding how much of it Salesforce keeps.
• What flows into Salesforce, what flows out, and what comes back.
• Which data Salesforce should own, copy, reference, federate, archive or leave alone.
• Which platform and infrastructure boundaries matter, rather than assuming everything branded Salesforce lives in one place.

The shift from developer to architect often isn’t learning another feature. It’s learning when to stop looking at Salesforce: pull the camera back, follow the data, find who owns the truth, then come back and decide what Salesforce’s job should be.

Explore

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), checked 2026-10-14.