Where Does This Data Live?

🌐 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 4 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Previous: Build Your Own: Custom Objects · Next: Choose the Right Object

The question this module answers: before you create an object, where should this data actually live: on core in Salesforce, referenced where it already sits, or archived?

Let me ask you a question. A new requirement lands on your desk. What’s the first thing you do?

If you’re like most of us, you open Setup and create a custom object. I get it. In ten minutes you’ve got a tab, a page layout and a list view. And here’s the thing I tell every class: the moment you create that new object, you’re already thinking like an architect, whether you meant to or not. Because every object you create is a commitment. It takes storage. It picks up limits. It gets a sharing model, whether you designed one or not. It needs a license for anyone who touches it. And once people and integrations depend on it, good luck taking it away.

So the first architecture decision isn’t which object. It’s where should this data live? Get that right and the object type almost picks itself.

On Core and Off Core

First, a word I’ll use a lot: core. Core is the Salesforce platform your org runs on: the metadata-driven, multitenant platform from module 1, where the Sales and Service objects from module 2 live, and every custom object you build in module 3. When I say data is on core, I mean it’s stored in your org, in its objects.

Not all data lives there. Data 360 keeps its data in its own store, outside your org’s objects (it’s near-core: managed on core, its data hosted off core; more in chapter 4). And then there’s everything your company runs that isn’t Salesforce at all: the ERP, the warehouse, the order system, the partner’s platform. All of that is off core. Salesforce can reach it, show it and use it, but your org doesn’t store it.

On core, there are two kinds of objects that actually hold your records: sObjects, standard and custom (__c), and big objects (__b). Off core, you reach data through external objects (__x) and the other integration tools. Keep those suffixes from module 3 in mind; they tell you where a piece of data lives just by its name.

I think about it like an office. Some things belong on your desk, where you use them every day. Some things you just need to look up in somebody else’s filing cabinet. And some things go in boxes in the shed out back. That gives me three answers.

1. On Core: It Lives on Your Desk

The data is created, changed and used in Salesforce every day: accounts, cases, opportunities, work orders. Keeping it in sObjects is like keeping it at the front of your office. This is what standard and custom objects are for, and you get everything: page layouts, sharing, automation, reporting, search, and now the AI features built on the data model.

Your desk isn’t free, though. On-core data costs storage, counted the way Salesforce counts it, record by record, not column by column, and documents count against file storage on their own. We covered both in module 2. Big volumes of photos and scans often belong off core, with Salesforce keeping only a link.

2. Referenced: It Lives in Somebody Else’s Filing Cabinet

The data belongs to another system (the ERP, a data warehouse, an order platform), and that system stays the source of truth. Users need to see it in Salesforce, maybe relate it to a record, but Salesforce doesn’t need its own copy. You’ll also hear this called virtual data: it shows up in Salesforce virtually, without ever being stored there.

That’s external objects, through Salesforce Connect. I like to say it looks like a duck and walks like a duck, but it’s not a duck. It shows up like an sObject: you can put it on page layouts and related lists, and relate it to your own records with external and indirect lookups. But the data isn’t stored on core. Every time you touch it, it makes a callout. Open a record, load a related list, run a report, and Salesforce goes and asks the other system. That means latency, and your page is only as available as the system behind it.

People push back on the license cost, so do the math the way I do in class. Connect is licensed per endpoint, and one endpoint can bring in many objects. Now ask what it costs to build and maintain the alternative: a custom component, the callout code behind it, and a developer on call when it breaks. Often the license is cheaper, and your admins can configure it without writing a line of code. Where it falls down: data your users edit all day, or report on heavily.

Documents can be referenced too. If a contract already lives in SharePoint Online, OneDrive, Google Drive or Box, Files Connect lets users reach it from Salesforce without copying it in.

Salesforce Connect isn’t the only way to reference data. Sometimes it’s custom logic: code that calls the other system in real time and renders its data on the page, with no copy kept. That gives you full control, and full responsibility for the callout, the errors and the upkeep. And Data 360 can federate without copying, too. That choice has its own chapter (Virtualization, Federation, and Zero-Copy). Here, the point is the decision itself: reference, don’t copy.

3. Archived: It Goes in the Shed Out Back

History, audit trails, old transactions. You have to keep it, sometimes for years, but almost nobody opens it. And this is the one teams put off. When a class tells me they’ve got an object with 50 million records and asks why they’d archive, I ask them back: if you’re not archiving today, are you ever going to archive? At 50 million today, you’re heading for 100, 150, 200 million.

There are two sheds. One is on core: big objects. Think of them as storing data in the garage. You can store a huge number of records, but you can’t put them on a page layout, there’s no standard UI or reporting, and you query through the big object’s index, by exact match or range (Big Objects Best Practices (opens in a new tab)). Security is object and field permissions only, with no record sharing, and automation doesn’t run on them. I’ve used Salesforce Connect dozens of times and big objects only once or twice. They work, but they’re awkward, and I’ve written my share of workarounds to get at the data. So my advice: prototype it before you suggest it, and plan how people will find the data before you choose it.

The other shed is off core: a warehouse or a database somewhere else (Designing for Scale). Often that’s the better shed, and it doesn’t have to be out of sight. Archived data off core can still show up in reports through tools like Tableau, and it can still be reachable from Salesforce, through Salesforce Connect or another way of virtualizing it, when someone needs to look back.

Let me tell you about a project where we got this right from the start. A retail client had over 1,200 locations. They told me, “We only do a hundred appointments a day at a store. No big deal.” Then I did the math: a hundred a day, six days a week (about 305 days a year), across 1,200 locations, is over 36 million appointments a year. Then they mentioned every visit created two appointments, one at the front counter and one for the back of the shop: over 73 million records a year. Then they wanted five years of history: more than 360 million records, before any growth. We hadn’t gone live, and I could already see the train heading straight for the large-data-volume station. So the archive was built before we collected a single appointment: older appointments moved to big objects, and the search screen showed current appointments with the archived ones right below. Years later, it’s still running fine.

Click to enlarge

Putting It to Work: Steve Trucking

Steve Trucking is our running scenario: a family-owned last-mile delivery company that picks up appliances and electronics at big-box retailers’ distribution centers, then delivers and installs them at customers’ homes. Four kinds of its data, three answers:

Data	Where it lives	Why
Today’s deliveries, crews and appointments	On core	Dispatchers and crews work in it all day
The retailer’s order details	Referenced (or a thin copy on core)	The retailer’s system is the source of truth
Delivery history from three years ago	Archived	Kept for claims and trends; almost nobody opens it
Delivery photos	Off core, linked	Thousands a day; stored outside Salesforce with a link on the delivery

Here’s the same thing as a data model. The Delivery sits on core, where people work in it all day. Three years on, it moves into Delivery History, a big object: still on core, but out in the shed. The partner’s order shows up as an external object, __x: Salesforce relates the delivery to it, but the data stays in the retailer’s system. And the photos live off core entirely, with a link from the delivery. One model, three homes.

Click to enlarge

Every real org has all three. The ones that get into trouble put everything on core, because creating an object was the default button.

What an Architect Decides Here

• The home for each kind of data, before any object is designed: on core, referenced or archived.
• The source of truth. If another system owns the data, Salesforce shouldn’t quietly become a second master.
• The access path for anything off core. Referenced data needs an available source and acceptable latency; archived data needs a way for people to find it.
• Storage growth. Do the math now (records per day, times growth, times retention), not when the storage warning arrives.

Beyond the exam: AI raises the stakes on “on core.” AI features and agents work best on data the platform understands: data in standard and custom objects, well named and well described. That’s a pull toward putting more on core. Resist it for the wrong data. An agent grounded on a stale copy of ERP data gives confident, wrong answers. Often the better move is to reference the live source, or to keep a small, well-described slice on core. Where AI reads the data is now part of deciding where the data lives.

Explore

• Big Objects Best Practices (opens in a new tab), Salesforce Developers (checked 2026-09-25)
• Files Connect FAQ (opens in a new tab), Salesforce Help (checked 2026-09-25)
• In this course: Virtualization, Federation, and Zero-Copy and Designing for Scale