Turn the Model into 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 6 of 6 in the chapter Modeling Data for Meaning, chapter 2 of the Data Architect course. Each module stands on its own. Previous: Design to Third Normal Form, Then Back Off · Next: the chapter study guide, then the next chapter: Salesforce Data Architecture

The question this module answers: How does a logical data model become a physical Salesforce data model?

We’re finally going to talk about Salesforce. If you’ve been resisting the urge to turn every box into an object, now you can. But notice the order we came in: we understood the business, described the data, put each fact where it belongs, and decided where we’d bend that on purpose. Only now am I asking how Salesforce should implement it. That’s the progression I want you to remember: conceptual → logical → physical. The conceptual model describes the business. The logical model describes the data. The physical model describes how we’re actually going to build it.

Sit, Stay, Model

The physical step is easiest to see on something small, so the pets go first.

Who are the businesses and the people? The breeder is a business, so it becomes an Account with a record type of Breeder. The owner is an Account too, or a person account, with a record type of Owner. Two kinds of the same standard object, side by side at the top of the diagram, right where they’ve been since module 1.

What has no standard home? Pet, Breed, Trick, Pet Trick and Trick Assessment become custom objects. And remember the species we copied onto the pet in module 5? Here it gets its job: it becomes the Pet’s record type, Dog or Cat. One object with two record types, each with its own page layout and picklist values, instead of a Dog object and a Cat object.

Which relationships are master-detail? I use master-detail only where the child will never be re-parented. A Pet Trick belongs to its pet for life, and each Trick Assessment belongs to its Pet Trick, so both are master-detail. That pays off right away: master-detail is what lets the pet keep a roll-up summary of its Pet Tricks, so the Tricks Known count from module 5 stays in step on its own. Pets do change homes, though, so the Owner is a lookup.

Which are lookups? Salesforce doesn’t recommend more than 10,000 children on a single parent. A popular trick like Sit, a common breed or a big breeder could pass that easily, so Pet Trick points at its Trick with a lookup, and the pet points at its Breed and Breeder the same way. And avoid polymorphic relationships where you can, the kind where one field can point at several object types. They’re convenient on day one and harder for everything that has to read them later: reports, integrations, and now agents.

What stays off the platform? If the pet wears a GPS collar that reports where it is, that location doesn’t need to be copied in at all. It can be an external object, read live from the collar’s tracking system.

Click to enlarge

Every decision on that diagram traces back to something we decided earlier, and that’s the point. Now the same step for Steve Trucking.

Start With the Logical Model

Our Steve Trucking logical model now holds Retail Partner, Distribution Center, Manifest, Delivery, Delivery Item, Recipient, Route, Stop, Crew, Truck and Crew Assignment. Those are business concepts, and now I can start mapping them to Salesforce.

A Retail Partner might be an Account. A delivery might map to something Salesforce already has for scheduled work in the field, or it might become a custom object. A manifest has nothing standard that fits, so it probably becomes custom. And the Recipient is a genuinely hard question: a Person Account, a Contact, or simply information on the delivery? We’ll answer that one properly in the next chapter.

The important word is still might. Don’t assume the implementation just because a business concept sounds like a Salesforce object. That’s why we built the logical model first: it gives us something to test the Salesforce design against.

A Business Entity Doesn’t Automatically Mean a Custom Object

Here’s a trap I want admins to avoid: “We identified eleven entities, so we need eleven custom objects.” No. A logical entity tells us the business concept matters. It doesn’t dictate how Salesforce must store it. A concept might become a standard object, a custom object, a relationship between objects, a field or a few fields, a value managed in configuration, or data that lives outside Salesforce altogether (Steve Trucking’s delivery photos are a good candidate for that). The physical model is where those choices are made, which is exactly why we didn’t make them on the first call.

Attributes Become Physical Fields

The same transition happens with attributes. Our logical Truck has a unit number, VIN, make, model, model year, license plate and status. Now we decide how they physically exist: which object owns them, what field types they use, which are required, which must be unique, which are external identifiers, which need validation, which are derived rather than stored, and which are sensitive. At the logical level we asked what Truck means. At the physical level we ask how Salesforce will represent Truck. Different questions.

Click to enlarge

Relationships Become Platform Decisions

All the time we spent on relationships pays off here. We already know whether each one is one-to-one, one-to-many or many-to-many, required or optional, and whether its history matters. Now we decide how Salesforce implements it: a lookup, a master-detail, or a Salesforce Junction Object, and maybe a junction with attributes of its own, because, as we found, the relationship itself can have business meaning.

Think back to the Crew Assignment. We could have started this chapter by saying, “Let’s create a Salesforce Junction Object between crew and truck.” Look at what we’d have skipped: why the relationship exists, whether it needs a date and a route, whether it has a status, and whether a damage claim weeks later needs its history. Those business questions tell us what a Crew Assignment is. Only then should we decide how Salesforce builds it, and whether Salesforce already has something that does the job.

Now Draw the Physical Model

The diagram changes again. The conceptual model showed business concepts and simple lines. The logical model added attributes, keys, cardinality and the entities hiding in relationships. Now the physical model starts to look like Salesforce: standard objects, custom objects, fields, relationship types, and what lives off-platform.

Click to enlarge

I want you to be able to put those three diagrams side by side and see the progression: not three unrelated diagrams, but the same business at three levels.

A word on how I draw these, because layout is part of the message. I put the primary object in the middle, slightly down. If it has parent objects, I put them slightly above, so you read the model top down, left to right, the way the business thinks about it. Reference data goes off to the side. Colour means something too: I always make Salesforce blue, and I choose a colour for the company’s own systems, usually green, because green’s a nice friendly colour. I don’t use red, and yellows are a little harsh. When a model is laid out like that, it sings to me. A lot of the diagrams you’ll find are really space management: how do I park all my cars in my congested garage? I’d rather paint a logical picture the mind can grasp.

The Physical Model Has to Respect the Platform

Salesforce isn’t a generic relational database. It has opinions about relationships, ownership, security and reporting. It has limits, query behavior and automation, and an architecture that affects how a model behaves at scale. So a logical model that looks perfect on a whiteboard may need to change when it becomes physical. That isn’t Salesforce getting in the way. It means the platform has a shape, and good architects understand that shape. The next chapter is about exactly that.

Sometimes, too, the physical model will deliberately differ from the clean logical model because of the denormalization decisions we made in module 5. That’s fine, as long as we can explain why.

Don’t Design From Setup

There’s a habit I want you to break if you have it: starting your data architecture at Setup → Object Manager → New Custom Object and figuring out the model as you go. Salesforce makes it incredibly easy to create things; that’s one of its strengths, and one of the reasons weak data models happen so fast. A few clicks and you have an object, a few more and you have fields and a relationship. Then data arrives, flows get built, reports get created, integrations depend on it, and the object you created in five minutes is very expensive to change. It’s the Reversibility Test from Chapter 1. So before you click New Custom Object, draw the model.

Physical Doesn’t Mean Permanent

There’s another reason I keep the three models separate: technology changes. Today some of Steve Trucking’s data lives on Salesforce core. Tomorrow part of it may live in Data 360, a warehouse, or a system we haven’t chosen yet, and the AI assistant needs its own representation. The physical architecture can change, while the business concepts stay remarkably stable: Retail Partners, deliveries and Recipients still exist. That’s what makes the logical model valuable. It’s a durable description of the business that isn’t tied to today’s implementation.

What an Architect Decides Here

When I turn a logical model into a physical Salesforce model, I’m deciding:

• Which business entities map to standard Salesforce capabilities, and which need custom objects or another representation.
• How logical attributes become physical fields, and how relationships are implemented on the platform.
• Where deliberate denormalization belongs in the physical design.
• Which data belongs on Salesforce, and which belongs somewhere else.
• Which platform characteristics require the physical model to differ from the logical one.

Most importantly, I want to be able to trace each decision backward. If you point at something in my physical model and ask, “Why is that there?”, I should be able to take you back through the logical model and the conceptual model to something the business actually needs: business → conceptual → logical → physical.

Beyond the exam: what AI changes. AI can now take a requirements document all the way to Salesforce objects and fields in one jump. That makes the sequence more important, not less: if it skips from requirements to configuration, ask it to show what happened in between: what it decided was an entity, which keys it chose, which relationships it assumed, and where it denormalized. Those are architecture decisions, and the architect still needs to see them.

We started this chapter on a first call, listening for nouns, and we end it with a physical model we can trace back to the business. Now that we’ve chosen to build on Salesforce, the next question goes deeper: what kind of data platform are we actually building on?

Explore

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (checked 2026-10-02): “configure parent-child relationships with no more than 10,000 children to one parent record.” A guideline about data skew, not a hard limit; chapter 7 goes deeper.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (checked 2026-10-12): a roll-up summary counts or sums detail records through a master-detail relationship.