Checkpoint challenge

Original, scenario-based practice. Never modeled on actual exam questions. It’s written in the “What I Would Architect” style: the point is making your judgment visible, not picking a letter. This challenge closes Part 1 of the Data 360 Architect course; my walkthrough is module 5. Try it first.

Scenario

Steve Trucking is a last-mile delivery company. Retail Partners sell appliances, TVs and furniture; Steve Trucking’s two-person crews deliver them to the Retail Partners’ customers, the Recipients, at home. Read the Steve Trucking brief for the whole company.

Steve Trucking runs one Salesforce org. Each delivery is a Work Order, keyed by the partner’s own reference in one field, such as KEYSTONE-PHX-8843119-1. The Recipient isn’t a contact or a person account: the Recipient’s name, email, phone and address are fields on the Work Order, because a Recipient is a Retail Partner’s customer, and one partner must never see another partner’s Recipients (S2).

Steve Trucking has Data 360, and Part 2 will build on it: unifying, insights, segments, actions. Before any of that, the first three sources have to come in and reach the model:

1. Deliveries and their Recipients, in the Salesforce org.
2. Tracking-page events. The day before a delivery, each Recipient gets a link to track the truck (R5, R6). The tracking page’s back end records what happens: the link opened, the window viewed, the photos viewed, a question asked.
3. Manifest lines. What each Retail Partner asked for, line by line, and every revision. The integration layer already receives every partner’s manifests; it can write each set and each revision as a CSV file to Amazon S3.

Requirements

• Every source reaches the data model, and the people data reaches the standard objects identity resolution will use (chapter 9).
• Part 2 must be able to compare what the partners asked for with what was delivered, and see how Recipients use the tracking page.
• A revised manifest line must not erase the line it revised.

Constraints

• About 3,300 deliveries a day, about 1 million a year, from three Retail Partners.
• About 3 tracking-page events per delivery.
• Recipients’ names, phones, emails, addresses and delivery notes are personal data (S4). Keep the copies to the minimum.
• A Recipient is never treated as the same person across two Retail Partners (S2).

Your task

For each of the three sources, decide and write down:

1. The door: pull or push, and which connector or API (chapter 4, chapter 5).
2. The category: profile, engagement or other, and for engagement, the event time (chapter 6).
3. The key: what makes each row unique, and how it’s built (chapters 3 and 6).
4. The path to the model: which data model objects each source maps to, standard or custom, and which fields you leave out (chapter 8).

Then draw the three paths, door to stream to lake object to model objects, and mark the keys that connect them.

Questions to think about

• The Work Order is a delivery. Is it profile, engagement or other? What does the Recipient on it change?
• The tracking page knows the delivery, from the link’s token. Does it know the person?
• The manifest carries the Recipient’s name and phone too. Do you need them twice?
• A planned delivery date can change when a Recipient reschedules (R9). What does that mean for the category?

Discussion

My walkthrough is in module 5. Compare your answer with it, and look hardest where you chose differently: there’s more than one defensible design, and the reasons matter more than the boxes.

Exam objectives exercised

From the Salesforce Certified Data 360 Consultant Exam Guide (opens in a new tab) (Spring ‘26; this course covers the consultant exam and goes beyond it):

• Data Source Connection and Ingestion (18%): “Describe processes and considerations for data ingestion from varied sources into Data 360.” Here: choosing the doors in, each stream’s category and its primary key.
• Harmonization and Unification (17%): “Model data in Data 360.” Here: mapping to standard and custom data model objects.