Design the Salesforce Physical Model

🌐 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 10 of 10 in the chapter Salesforce Data Architecture, chapter 3 of the Data Architect course. Each module stands on its own. Previous: Keeping Data Consistent · Next: the chapter study guide, then the next chapter, Understanding Enterprise Data

The question this module answers: How do we turn our logical model into a Salesforce architecture?

This chapter has been one long argument that the platform has a shape: standard and custom objects, places data can live, field types, relationships, ownership, licenses, consistency rules, storage and scale. Each one can change how chapter 2’s logical model gets built. Now let’s put it together on one slice of Steve Trucking.

One slice, not the whole company. A mistake I see architects make is trying to solve the entire enterprise in one diagram. I want something we can reason about: a Retail Partner sends a manifest, Steve Trucking delivers what’s on it, and we keep what we need about each delivery. Then we make the physical decisions one at a time. The full design is the Part 1 checkpoint.

Start With What We Already Know

Chapter 2 did the conceptual work: Retail Partner, Recipient, Manifest, Delivery, Delivery Item, the kind of stop, Crew, Truck, Distribution Center, photos. We named the relationships and asked what they mean. I won’t repeat that. The question now is how those concepts live on Salesforce. One fact from the brief matters straight away: Steve Trucking already runs Field Service for appointments, crews and the mobile app.

Retail Partner: Don’t Invent an Account

A Retail Partner is a company Steve Trucking works for. Salesforce already has an object designed for companies: Account. Clean fit. So no Retail_Partner__c just because the business says “partner.” It’s an Account, with a Retail Partner record type to tell it apart from other organizations, and with it come contracts, cases, Contacts for the DC managers, and portal access for those Contacts. Easy decision. Not all of them are.

The Partner’s Order Number Isn’t Our Identity

Each Retail Partner sends its own references. One partner’s order looks like 8843119, another’s like A-984732. Those numbers matter, but whose are they? The partner’s. Salesforce has its own record ID, and the partner has the reference it uses when it talks to us. Both can exist; that’s chapter 2’s “one thing, several identifiers.”

So the partner’s reference becomes an External ID that the integration uses to match updates. And because two partners could use the same number, the identity is the partner plus the reference, not the reference alone. Don’t make a partner’s number the universal identity of the delivery because it arrived first, and don’t make an integration search a text field every time it needs to find a record.

Delivery: Look to the Mothership

Here’s where it’s tempting to create Delivery__c. The business said “delivery,” so we need a Delivery object. That’s exactly what I don’t want you to do first. Look to the mothership, as we did in module 2. What does Salesforce already have for work performed at a location, with a lifecycle, items, scheduling and a crew in the field? Field Service’s Work Order: Salesforce describes it as field service work to be performed for a customer (WorkOrder (opens in a new tab)). The scheduled visit and its time window is the Service Appointment, and that’s what dispatch schedules and the crew’s app shows.

So Delivery → Work Order. Not because the words match; they don’t. Because the behavior matches the platform capability we’re already paying for and intend to use. A standard object doesn’t have to share the business vocabulary. It has to represent the concept correctly.

Click to enlarge

Step 1 of 4: the mothership. Each card is the business concept, with its Salesforce object underneath.

But Standard Objects Come With Baggage

The other half: Work Order isn’t free. It brings Field Service licensing, its own relationships, security behavior, required fields, automation and lifecycle, and other parts of the platform expect it to behave a certain way. We’re choosing it because the fit is clean and we’re using what’s built around it. If Steve Trucking wanted none of Field Service and the model fought the process at every turn, I’d reconsider. The architecture is the fit, not the label.

Delivery Items: Follow the Model

Once Delivery is a Work Order, look at the rest of that model before inventing anything. A Work Order Line Item is a subtask on a work order (WorkOrderLineItem (opens in a new tab)): the refrigerator, the install, the haul-away. So Delivery Item → Work Order Line Item. Notice the first decision shaped the second. We’re not choosing an object for each entity on its own. Adopt a model, and understand the rest of it before you build custom structures around it.

What Kind of Stop Is This?

At Steve Trucking a stop is delivery only, delivery with install, or delivery with haul-away, and each kind has its own duration, crew skills and install checklist. In chapter 2 we decided that’s an entity, not a label. Field Service already has one: Work Type, a template for a type of work that can be applied to work orders and line items (WorkType (opens in a new tab)). So Kind of Stop → Work Type. Again, not because something called Work Type exists, but because the concept and the behavior line up.

Click to enlarge

Step 2 of 4: follow the model. Line items and Work Type come with the Work Order.

Manifest: Now I Want a Custom Object

Is there a standard object for “the partner’s list for Tuesday at the Phoenix DC”? Not really, and I won’t force it into an unrelated object just to say we stayed standard. Manifest → Manifest__c. It’s the unit of receipt: where it came from (a file, an API batch), when, its status and totals, and, when a partner re-sends it on the day, what gets compared. Each manifest line becomes a Work Order linked back to it.

Custom isn’t failure. It’s what the platform gives us when a concept has no clean standard home. The mistake isn’t creating a custom object; it’s creating one without checking whether the platform already has the concept.

Click to enlarge

Step 3 of 4: the one custom object, where no standard object fits.

Photos: Just Because Salesforce Can Store It Doesn’t Mean It Should

“We need the delivery photos in Salesforce.” What does “in Salesforce” mean? Users need to see them from Salesforce, yes. Does that mean the image files have to live in core storage? Not necessarily. Count the zeros: about four photos a delivery, more with installs, at a million deliveries a year, is four to five million photos a year, and deliveries grow 30% a year.

So my starting position: don’t turn the core org into a giant photo repository because users need access to photos. The files belong in storage built for that volume, outside the core, with Salesforce keeping what it needs to find and show them: a reference, a count, or a small index record per photo, and a flag that the required install photos are complete. Access to data and where the data physically lives are two different questions. That’s module 4 coming back.

Fields: Make the Meaning Visible

The Work Order needs fields: the partner’s reference, the delivery window, the actual delivery time, status, notes like “gate code” or “dog in the yard.” I won’t turn this into a field catalog; module 6 did that. Run the questions on each: what it means, who owns it, whether it changes, whether it’s an identifier, a controlled vocabulary, stored or derived, sensitive. The partner’s reference is the External ID, so its uniqueness is part of the integration contract, not just a checkbox. The actual delivery time is a moment, so Date/Time. Status drives behavior, so a controlled list, never free text. And delivery notes about a person’s home are personal data, so they get classified. Each field traces back to meaning.

Relationships: Don’t Just Connect the Boxes

Account to Work Order, Work Order to its line items, Manifest to Work Order, Work Type describing the stop. Then module 7’s questions for each line: can the child exist alone, who owns it, does access inherit, can it move, what happens on delete, how many children can pile up? Every Work Order under a handful of Retail Partner accounts means hundreds of thousands of children per parent: a skew question we’ll answer in Part 2. And for the standard Field Service relationships, check how Salesforce already built them rather than assuming they match what we’d have designed. When you adopt a standard model, you adopt the decisions Salesforce made inside it. Understand them before you build on top.

Ownership and the Recipient: Don’t Let the Default Decide

Two decisions that a default would happily make for us.

Who owns a delivery? We answered this in module 8, and it carries straight over to the Work Order: ownership doesn’t drive anyone’s access here, so the integration user owns the Work Orders it creates. Dispatchers see their distribution center’s, crews see their routes’, and each Retail Partner sees its own through the portal, all through sharing, not ownership. The integration user has no role and stays out of the public groups our sharing rules use, because at 3,300 a day it passes 10,000 records in three days. And we write down what happens if that user is ever replaced.

What is the Recipient? A Contact? A person account? Something kept only on the delivery? It depends on whether Steve Trucking has a relationship with these people at all (they’re the Retail Partners’ customers), whether one partner may ever see another’s, how long their personal data may be kept, and the scale: about a million new Recipients a year. We don’t have all of that yet, and that’s fine. Sometimes the right answer is we don’t know enough yet. Write the question down and go get the information; don’t bury the uncertainty in a custom object. We answer it at the Part 1 checkpoint, after chapters 4 to 6 give us the enterprise and master-data picture.

Consistency: Protect the Model at the Right Layer

Module 9’s ladder applies: the partner’s reference is an External ID, unique, so a re-sent manifest upserts instead of duplicating; status is a restricted list; the actual delivery time is required only once the status says Delivered; an install stop can’t close without its checklist and photos. Not one giant flow. Each rule on its own rung.

Where Each Piece Lives

One more pass over the slice, with module 4’s question: where does each piece of data live? In my class deck it’s one slide, logical against physical: the logical entities from chapter 2, and where each one physically lands: on core, as an sObject (__c if it’s custom) or a big object (__b), or off core, as an external object (__x) or data that never comes into Salesforce at all.

• On core, worked in every day: the Account, the Work Orders and their line items, the Service Appointments, the Work Types, Manifest__c.
• On core, archived: deliveries older than three years move to Delivery History, a big object, still there for claims, out in the shed.
• Referenced: the Retail Partner’s own order details stay in the partner’s system; we keep the partner’s reference as an External ID, and reach the rest through an external object or the integration when someone needs it.
• Off core: the photos, in storage built for millions of images, with a link from the Work Order.

That’s the physical model: not only which object, but which home.

Now Look at the Whole Slice

• Retail Partner → Account, with a Retail Partner record type; DC managers as Contacts.
• Delivery → Field Service Work Order, scheduled through a Service Appointment.
• Delivery Item → Work Order Line Item.
• Kind of Stop → Work Type.
• Manifest → custom Manifest__c.
• Partner reference → External ID on the Work Order, unique per partner.
• Photos → stored off-core; Salesforce keeps the reference and the completeness flag.
• Delivery history → archived to a big object after three years.
• Ownership → the integration user, with access through sharing (module 8).
• Recipient → open, for the Part 1 checkpoint.

Click to enlarge

Step 4 of 4: the whole slice, on core, archived and off core. Every line is a lookup: Salesforce built Field Service on lookups, and we adopt its decisions with it.

The Diagram Isn’t the Architecture

I can hand you that diagram, and it isn’t enough. The architecture is the reasoning behind it. Why Account? A clean-fit company. Why Work Order and not Delivery__c? The delivery behaves like field work, and Field Service is already in place. Why a custom Manifest? No clean standard home. Why aren’t photos just Files? Volume and storage economics. Why an External ID? Another system needs a stable identity across the boundary. Why does the integration user own the Work Orders? Ownership doesn’t drive access here, and that keeps the audit trail honest. Why is the Recipient still open? We haven’t answered enough questions yet. The lines are the output; the decisions produced them.

So here’s the habit I want you to leave chapter 3 with. Point at anything in a physical model and ask why? Why this object, this type, this relationship, this owner, this place, this rule? You should be able to trace the answer back: from configuration, to the physical model, to the logical model, to the business requirement. If you can’t, somebody designed from Setup.

And you’ll have noticed the numbers we haven’t fully worked: deliveries per partner, line items, photos, retention, archiving. Good. Ask for the number of zeros before you lock in a design: a model that works beautifully at fifty thousand records can behave very differently at five hundred million. That’s Part 2.

Beyond the exam: what AI changes. Give an AI the Steve Trucking brief and it will produce a schema in seconds: Account, Work Order, custom objects, fields, even deployment metadata. That’s a fantastic accelerator, and it isn’t the review. The architect’s job shifts to checking the mappings and their consequences: fit, licenses, ownership, lifecycle, scale, identity, security and what stays off-platform. AI is the rocket booster; it doesn’t tell you whether you’re pointed in the right direction.

What an Architect Decides Here

• How each business concept maps to Salesforce: a standard object, a custom object, or something outside the core.
• Which identifiers, fields and relationships implement the business meaning without quietly changing it.
• What platform behavior and licensing come with a standard model you adopt.
• Which ownership, lifecycle, consistency, storage and scale decisions must be made before the design is complete.
• Which questions stay explicitly open, rather than hidden behind an arbitrary implementation choice.

At the start of this chapter we asked how the model should live on Salesforce. That’s Salesforce data architecture: not creating objects, not memorizing Setup, not drawing prettier boxes, but deliberately fitting the business model to the shape of the platform. Every structure is a commitment. Make the ones you can explain.

Explore

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) and WorkType (opens in a new tab), checked 2026-10-02.
• The Steve Trucking brief.