Steve Trucking, What I Would Architect

🌐 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 Master Data and Identity, chapter 6 of the Data Architect course, and the end of Part 1. Previous: When Authority Is Shared · Next: Part 2 begins with Designing for Scale (coming soon)

The question this checkpoint answers: Can you put Part 1 together on a real scenario?

Try the challenge first. This is my walkthrough of Checkpoint 1’s challenge. If you haven’t drawn your own design yet, do that before you read on. The value is in comparing your reasoning with mine, not in reading the answer.

This is “What I Would Architect”: a possible viable solution, not the answer, with the trade-offs named and my positions taken. We haven’t covered large data volumes, query design, integration patterns, migration or transactions yet, and that’s on purpose: architecture develops as you learn more. But Part 1 gives us enough to set the bones.

Start With the Numbers

From the brief: about 3,300 deliveries a working day, a million a year, growing 30% a year. About 1.6 line items a delivery (1.6 million a year); about eight status changes a delivery (8 million a year); four to five million photos a year; about 200,000 GPS readings a day; about 180,000 cases a year; three Retail Partners sending manifests three different ways; nine distribution centers; 330 trucks with two-person crews. And Steve Trucking already runs one Salesforce org with Service Cloud, Field Service and a partner portal. Count the zeros before drawing a single box. They’ll decide several things below.

The Delivery Core: Look to the Mothership

The deliveries are the heart of it, and Field Service already does dispatch. So I start with Field Service’s standard model, as chapter 3’s slice did:

Business concept	Salesforce object	Why
Retail Partner	Account (Retail Partner record type)	A business Steve Trucking contracts with; carries contracts, cases and portal access
Partner staff (DC managers, store staff)	Contact	Portal users must be Contacts
One delivery: one Recipient, one address, one partner order, one day	Work Order	Field Service’s unit of work; scheduling, the mobile app and service reports hang off it
Each item or service: the fridge, the install, the haul-away	Work Order Line Item	Divides the work, drives checklists and invoicing
The kind of stop: delivery only, with install, with haul-away	Work Type	Sets duration, skills and the install checklist
The scheduled visit and its window	Service Appointment	What Field Service schedules and the crew’s app shows
Crews and trucks; DC dispatch areas	Service Resource, Service Crew, Service Territory	Field Service schedules a crew as one resource
Recipient inquiries, partner claims	Case	The service console, entitlements, email-to-case
The partner’s list for Tuesday at the Phoenix DC	Manifest__c (custom)	Nothing standard represents the unit of receipt, reconciliation and replay

Everything else stays standard. Resisting more custom objects is deliberate: chapter 1’s question was when an architect should resist another one, and here the answer is “almost always.” The partner’s order line, for instance, isn’t a new object. It’s the Work Order, identified by the partner’s reference.

Click to enlarge

It grows from chapter 3’s finale (Design the Salesforce Physical Model): the same objects in the same places, with the crew, the dispatch area, the case and what Checkpoint 1 keeps off core added.

The Key That Matches a Partner’s Order to a Delivery

Each manifest line becomes one Work Order, linked to its Manifest. The key is the question I most want answered: how do we know that this line from the partner is that delivery? My answer: an External ID on the Work Order built from the Retail Partner and the partner’s own order and delivery reference (something like KEYSTONE-PHX-8843119-1), marked unique. One field per source, one-to-one. It’s the partner’s identifier, not ours: chapter 2’s “several identifiers for one thing,” and module 1’s “the partner owns its order reference.”

Why it matters: manifests arrive one to two days ahead and get revised on the day. With that key, every re-sent or revised manifest upserts instead of creating duplicates. The revision updates the Work Order, a field records it, and a change to an already-routed delivery alerts the coordinator: the partner’s change is applied, but flagged until dispatch confirms it. This is also what changes from chapter 4’s picture. Today every manifest lands in RouteDesk, and coordinators rekey routes into Salesforce and completed stops back. In this design the manifests come straight into Salesforce, upserted by the partner’s key; RouteDesk retires, and the rekeying ends. The Integration chapter designs the three inbound formats. The data decision is the key.

The Recipient: Person Account, Contact, or Neither?

This is the most interesting data decision in Part 1, so here are the options, then my choice.

Option A: person accounts. Each Recipient becomes a person account, linked to every delivery. For: standard, works naturally with Service Cloud, messaging and the console, recognizes repeat Recipients. Against: about a million new Recipients a year, each a person account at roughly twice a business account’s storage (Estimated Record Size by Object Type (opens in a new tab)), so within two years one of the largest objects in the org. And Recipients aren’t Steve Trucking’s customers. They’re each Retail Partner’s customers, and Steve Trucking must never blend one partner’s customer with another’s (S2).

Option B: Contacts under the Retail Partner’s account. Against: a million Contacts under three or four accounts is parent-child skew on a massive scale, far past Salesforce’s guidance of about 10,000 children per parent (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). This is the option to show, and reject.

Option C: the Recipient lives on the delivery. The Recipient’s name, phone, email, address and delivery notes are fields on the Work Order (the address fields are already standard there), captured from the manifest. For: no new large object; the data lives exactly as long as the delivery needs it; deletion happens per delivery, on the partner’s schedule; and partner isolation comes free, because each delivery belongs to one partner. Against: a repeat Recipient isn’t recognized as the same person.

That’s the balance to strike. Is there ever going to be a need to recognize several deliveries as the same person, at the same place? To give that person a login? That’s the line between a Recipient who needs a record of their own and Recipient details that are simply data about the delivery. And there’s a middle path. Carry the Retail Partner’s own customer ID as a field on the delivery, a Retail Partner Customer ID. It doesn’t create a Recipient record, but it ties together the deliveries a partner sends for the same customer, which is the start of a more unified customer experience, and it leads straight back to the Retail Partner’s system, where that customer really lives. It’s their identifier, so it only means something together with the partner: one partner’s customer 4417 has nothing to do with another’s.

In my professional opinion, Option C is the right choice. The not-recognized part is acceptable, even desirable: Steve Trucking has no relationship with these people beyond the delivery. It’s module 1 again: the Recipient is the partner’s customer, and the partner is the authority for who they are. And it’s chapter 5: personal data that lands in one place, tied to one delivery, is far easier to protect, retain and delete. And it holds up to chapter 2’s normal forms: the Recipient’s details are one-to-one with the delivery, so they belong on it. A separate Recipient child would save a few repeated values at the cost of another object, another relationship and its overhead, and the only way it would save more is by treating the same person as one across Retail Partners, which we won’t do. So the delivery carries the Recipient, with the Retail Partner Customer ID as the way back to the partner’s own system.

Click to enlarge

Would I Unify Recipients Across Partners?

John Smith, 123 Main Street, appears in Redrock’s manifest and Brightwave’s. Probably the same person. Should Steve Trucking unify them? No, deliberately not. Unifying Recipients across Retail Partners would breach S2: a partner must never see another partner’s Recipients, and a unified identity is exactly the bridge that leaks. It’s this chapter’s position applied: under-match where blending is costly, and here blending is very costly.

If a Retail Partner later wants repeat-Recipient recognition within its own deliveries, that’s a job for an identity-resolution tool, such as Data 360’s, scoped to that partner: a registry-style map, not a person account, and never across partners. A map of who’s who doesn’t grant ownership, and it doesn’t grant access.

What Stays in the Org, and What Doesn’t

Chapter 3 asked where data should live. The zeros answer it here:

• Current status lives on the Service Appointment and Work Order. The history of status changes, about 8 million a year and growing, doesn’t need to live in the core org. Each change is published as an event and kept in the warehouse, Snowflake. The org keeps the current state; the history is still there for service, operations and analytics, just not in the operational database.
• Photos (four to five million a year, some showing people or the inside of a home) live off-core in storage built for that volume, uploaded straight from the crew’s app. The org keeps only what it needs: a small index record per photo, or just a count and a “required install photos complete” flag. My preference is the lighter option: keep the org lean, and let the photo store own its index and retention.
• GPS readings (200,000 a day) stay in FleetLink and go to Snowflake; the org needs only the latest position for the tracking page and the dispatcher’s map.
• RouteDesk’s eight years of history (about 5 million deliveries) go to the warehouse or an archive, reachable for claims. What, if anything, comes into the org is a migration decision for Part 2.

Click to enlarge

Checkpoint 1: what I would architect. Same places as chapter 4’s landscape (Steve Trucking’s Landscape), with the rekeying and the spreadsheet gone.

Who Sees What, and Who Needs a License

• Retail Partners see only their own deliveries (S2). Every Work Order carries its Retail Partner; portal users see their partner’s deliveries, and DC managers only their DC’s.
• Partner users need a portal license that supports sharing rules and roles: Customer Community Plus or Partner Community. Chapter 3’s stadium seats: the cheapest seats don’t get the sharing this design needs. Both licenses need roles for the external users, and Salesforce warns that more roles slow the org down (Experience Cloud User Licenses (opens in a new tab)). A role per partner and per DC is fine; a role for every store isn’t.

Test knowledge. Know which external licenses carry standard sharing: Customer Community Plus and Partner Community (with roles for the external users), not Customer Community, which uses sharing sets.

• Recipients need no license. The tracking page shows one delivery through a link with a token that expires (S3), not a login.
• Watch the skew. Hundreds of thousands of Work Orders a year pointing at three or four partner accounts is account data skew. One option is a child account per DC under each partner, which spreads the children nine or more ways; archiving completed deliveries after the claims window keeps the active children per parent low. Part 2 takes that on.

What I Would Not Do

I wouldn’t create a person account for every Recipient because a Recipient is an individual. I wouldn’t hang a million Contacts off three accounts. I wouldn’t build a custom Delivery object beside Field Service’s Work Order. I wouldn’t unify Recipients across partners. I wouldn’t put millions of photos or GPS readings in core storage. And I wouldn’t call a unified Recipient a golden record unless we’d actually made a mastering decision.

What’s Still Open

Part 1 set the bones; Part 2 tests them. The LDV ruler at year three (Work Orders, Service Appointments and line items are all large-volume territory within two to three years), query design for partner-scoped list views, the three inbound integrations and three status feeds, the RouteDesk migration, transactions on the day, and the security design behind the portal. Steve Trucking will change, too. Keep this design; you’ll revisit it.

What an Architect Decides Here

• Which standard objects carry the core (here, Field Service’s), and which custom objects are truly justified (here, one).
• The key that matches each partner’s order line to a delivery, and why it belongs to the partner.
• What the Recipient is, based on the relationship Steve Trucking actually has with them.
• Whether to unify identities, and where blending is too costly to risk.
• What stays in the org, what lives off-core, and which licenses the design depends on.

Explore

• The Steve Trucking brief and challenges (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab) Considerations for Object Relationships (opens in a new tab) and Experience Cloud User Licenses (opens in a new tab), checked 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab), as cited in chapter 3.