Checkpoint challenge

🌐 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)

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 Architect course; my walkthrough comes in Checkpoint 1, so try it first.

Scenario

Steve Trucking is a last-mile delivery company. Big-box Retail Partners sell appliances, TVs and furniture; Steve Trucking’s two-person crews deliver them to the Retail Partners’ customers (the Recipients), install some of them and haul the old ones away. Read the Steve Trucking brief, sections 1–8. Leave section 9 (the late changes) alone; those come at the end of the course.

Requirements

Everything in the brief’s section 5 (R1–R15) and section 6 (S1–S5). The ones this checkpoint leans on most:

• R1. Receive each Retail Partner’s manifests in its own format (SFTP file, API, EDI) and turn them into routes, stops and line items without retyping.
• R3. Each Retail Partner’s DC managers see their own deliveries, exceptions, photos and claims in the portal, and never another partner’s.
• R4. Manifests are revised on the day; changes after routing must be handled.
• S2. A Retail Partner must never see another partner’s deliveries, pricing, volumes or Recipients.
• S3. The Recipient’s tracking link shows only that one delivery, without an account, and expires.
• S4. Recipients’ addresses, phone numbers and delivery notes are personal data; crews see them only for their own stops, only on the day.

Constraints

• About 3,300 deliveries a working day, a million a year, growing 30% a year; about 1.6 line items and eight status changes per delivery; four to five million photos a year; about 200,000 GPS readings a day.
• One Salesforce org in the US, already running Service Cloud, Field Service and a partner portal; MuleSoft licensed; Data 360 licensed but not implemented.
• Three Retail Partners, three integration styles; nine distribution centers.

Your task

Draw and defend the Part 1 design. Use what you’ve learned in chapters 1–6:

1. The landscape (chapter 4): draw Steve Trucking’s current-state system landscape in Steve’s layout, every arrow labeled with what moves and how.
2. The model (chapter 2): model the deliveries domain conceptually, then logically. Retail Partners, distribution centers, manifests, deliveries, line items, routes, trucks, crews, install checklists, photos, signatures, exceptions and Recipients. (Challenge D1.)
3. The physical design (chapter 3): which of those are standard objects (Field Service has work orders, service appointments, service resources and service territories) and which are custom? Which licenses do the partner users and the Recipients need? Where does each kind of data live: in the org, off-core, in the warehouse?
4. The key (this chapter): what key matches a Retail Partner’s order line to your delivery, and what happens when the manifest is revised after routing? (Challenge D3.)
5. The Recipient (this chapter): a Contact, a person account, or neither? Argue it from the relationship, the volume, partner isolation and the data’s lifecycle.
6. Unify or not (this chapter): Recipients appear in several partners’ manifests, sometimes more than once a year. Would you unify them, or deliberately not? What’s the risk, given S2? (Challenge DC1, without the late changes.)
7. Authority: for five key fields (the partner’s order reference, the delivery status, the Recipient’s phone number, the delivery window, the partner’s legal name), say who creates it, who owns it, which system is authoritative and who may change it.

Write each decision as both options, then your choice: “in my professional opinion…”

Discussion

My walkthrough is Checkpoint 1: Steve Trucking, What I Would Architect. Compare your reasoning, not just your boxes. Where you chose differently, can you say what you’d gain and what you’d give up?

Design review

Hold your design for now. Part 2 tests it against volume, queries, integration, migration, transactions and security, and chapter 18’s review card checks it at year three.

Exam objectives exercised

• DM-1, DM-2 (data model design; the model respects sharing)
• MDM-1, MDM-2, MDM-3, MDM-4 (mastering, authority, matching, traceability)
• SDM-1 (licenses), SDM-3 (a single view, and when not to build one)