Steve Trucking, co bych navrhl já

🌐 K dispozici také v 29 jazycích

English · 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)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 6 z 6 kapitoly Kmenová data a identita, kapitoly 6 kurzu Data Architect, a konec části 1. Předchozí: Když je autorita sdílená · Další: část 2 začíná kapitolou Návrh pro velké měřítko (coming soon)

Otázka, na kterou tento kontrolní bod odpovídá: Dokážete dát část 1 dohromady na skutečném scénáři?

Nejdřív zkuste úkol. Tohle je můj průchod úkolem Kontrolního bodu 1. Pokud jste ještě nenakreslili vlastní návrh, udělejte to, než budete číst dál. Hodnota je v porovnání vašeho uvažování s mým, ne ve čtení odpovědi.

Tohle je „Co bych navrhl já“: možné schůdné řešení, ne ta odpověď, s pojmenovanými kompromisy a s mými postoji. Velké objemy dat, návrh dotazů, integrační vzory, migraci ani transakce jsme ještě neprobrali, a to záměrně: architektura se vyvíjí, jak se učíte víc. Část 1 nám ale dává dost na to, abychom postavili kostru.

Začněte čísly

Ze zadání: asi 3 300 doručení za pracovní den, milion ročně, s růstem 30 % ročně. Asi 1,6 řádkové položky na doručení (1,6 milionu ročně); asi osm změn stavu na doručení (8 milionů ročně); čtyři až pět milionů fotek ročně; asi 200 000 údajů z GPS denně; asi 180 000 případů ročně; tři maloobchodní partneři, kteří posílají manifesty třemi různými způsoby; devět distribučních center; 330 kamionů s dvoučlennými posádkami. A Steve Trucking už provozuje jeden org Salesforce se Service Cloud, Field Service a partnerským portálem. Spočítejte nuly dřív, než nakreslíte jedinou krabici. O několika věcech níže rozhodnou ony.

Jádro doručení: dívejte se na mateřskou loď

Srdcem jsou doručení a dispečink už dělá Field Service. Začínám tedy standardním modelem Field Service, stejně jako výřez v kapitole 3:

Obchodní pojem	Objekt Salesforce	Proč
Maloobchodní partner	Account (typ záznamu Retail Partner)	Firma, se kterou má Steve Trucking smlouvu; nese smlouvy, případy a přístup na portál
Lidé partnera (vedoucí DC, personál prodejen)	Contact	Uživatelé portálu musí být kontakty
Jedno doručení: jeden příjemce, jedna adresa, jedna objednávka partnera, jeden den	Work Order	Jednotka práce ve Field Service; visí na ní plánování, mobilní aplikace i servisní zprávy
Každá položka nebo služba: lednička, instalace, odvoz	Work Order Line Item	Dělí práci, řídí kontrolní seznamy a fakturaci
Druh zastávky: jen doručení, s instalací, s odvozem	Work Type	Určuje dobu trvání, dovednosti a kontrolní seznam instalace
Naplánovaná návštěva a její okno	Service Appointment	Co Field Service plánuje a co ukazuje aplikace posádky
Posádky a kamiony; dispečerské oblasti DC	Service Resource, Service Crew, Service Territory	Field Service plánuje posádku jako jeden zdroj
Dotazy příjemců, reklamace partnerů	Case	Servisní konzole, nároky, e-mail na případ
Seznam partnera na úterý pro DC ve Phoenixu	Manifest__c (vlastní)	Nic standardního nereprezentuje jednotku příjmu, odsouhlasení a opakovaného zpracování

Všechno ostatní zůstává standardní. Odolávat dalším vlastním objektům je záměr: otázka z kapitoly 1 zněla, kdy by měl architekt odolat dalšímu, a tady je odpověď „téměř vždycky“. Řádek objednávky partnera například není nový objekt. Je to Work Order, identifikovaný partnerovou referencí.

Kliknutím zvětšíte

Vyrůstá z finále kapitoly 3 (Navrhněte fyzický model v Salesforce): stejné objekty na stejných místech, s přidanou posádkou, dispečerskou oblastí, případem a tím, co Kontrolní bod 1 drží mimo core.

Klíč, který páruje objednávku partnera s doručením

Z každého řádku manifestu se stane jeden Work Order, propojený se svým manifestem. Klíč je otázka, na kterou nejvíc chci odpověď: jak poznáme, že tento řádek od partnera je tamto doručení? Moje odpověď: External ID na Work Order složené z maloobchodního partnera a partnerovy vlastní reference objednávky a doručení (něco jako KEYSTONE-PHX-8843119-1), označené jako jedinečné. Jedno pole na zdroj, jedna k jedné. Je to identifikátor partnera, ne náš: „několik identifikátorů pro jednu věc“ z kapitoly 2 a „partner vlastní svou referenci objednávky“ z modulu 1.

Proč na tom záleží: manifesty přicházejí den až dva předem a v den doručení se upravují. S tímto klíčem každý znovu odeslaný nebo upravený manifest provede upsert, místo aby vytvářel duplicity. Úprava aktualizuje Work Order, pole ji zaznamená a změna doručení, které už je na trase, upozorní dispečera: změna od partnera se použije, ale je označená, dokud ji dispečink nepotvrdí. Tohle je také to, co se mění oproti obrázku z kapitoly 4. Dnes každý manifest přistane v RouteDesk a dispečeři přepisují trasy do Salesforce a dokončené zastávky zpátky. V tomto návrhu přicházejí manifesty přímo do Salesforce, upsertované podle klíče partnera; RouteDesk se vyřadí a přepisování skončí. Tři příchozí formáty navrhne kapitola o integraci. Datovým rozhodnutím je klíč.

Příjemce: osobní účet, kontakt, nebo nic z toho?

Tohle je nejzajímavější datové rozhodnutí části 1, takže tady jsou možnosti a pak moje volba.

Možnost A: osobní účty. Každý příjemce se stane osobním účtem, propojeným s každým doručením. Pro: standardní, přirozeně funguje se Service Cloud, zasíláním zpráv a konzolí, rozpozná opakované příjemce. Proti: zhruba milion nových příjemců ročně, každý jako osobní účet se zhruba dvojnásobným úložištěm oproti firemnímu účtu (Estimated Record Size by Object Type (otevře se v nové kartě)), takže do dvou let jeden z největších objektů v orgu. A příjemci nejsou zákazníky Steve Trucking. Jsou to zákazníci jednotlivých maloobchodních partnerů a Steve Trucking nikdy nesmí smíchat zákazníka jednoho partnera se zákazníkem jiného (S2).

Možnost B: kontakty pod účtem maloobchodního partnera. Proti: milion kontaktů pod třemi nebo čtyřmi účty je skew nadřazený-podřízený v obrovském měřítku, daleko za doporučením Salesforce zhruba 10 000 podřízených záznamů na jeden nadřazený (Considerations for Object Relationships (otevře se v nové kartě); Parent-Child Data Skew (otevře se v nové kartě)). Tuto možnost ukázat a zamítnout.

Možnost C: příjemce žije na doručení. Jméno, telefon, e-mail, adresa a poznámky k doručení příjemce jsou pole na Work Order (pole adresy tam už jsou standardně), převzatá z manifestu. Pro: žádný nový velký objekt; data žijí přesně tak dlouho, jak je doručení potřebuje; mazání probíhá po doručeních, podle harmonogramu partnera; a izolace partnerů je zadarmo, protože každé doručení patří jednomu partnerovi. Proti: opakovaný příjemce není rozpoznán jako stejná osoba.

To je ta rovnováha, kterou je třeba najít. Bude někdy potřeba rozpoznat několik doručení jako stejnou osobu na stejném místě? Dát té osobě přihlášení? To je hranice mezi příjemcem, který potřebuje vlastní záznam, a údaji o příjemci, které jsou prostě daty o doručení. A existuje i střední cesta. Neste na doručení jako pole vlastní zákaznické ID maloobchodního partnera, Retail Partner Customer ID. Nevytváří záznam příjemce, ale propojí doručení, která partner posílá pro stejného zákazníka, což je začátek jednotnějšího zákaznického zážitku, a vede přímo zpátky do systému maloobchodního partnera, kde ten zákazník doopravdy žije. Je to jejich identifikátor, takže něco znamená jen spolu s partnerem: zákazník 4417 jednoho partnera nemá nic společného se zákazníkem 4417 jiného.

Podle mého odborného názoru je správnou volbou možnost C. To, že příjemce není rozpoznán, je přijatelné, dokonce žádoucí: Steve Trucking nemá s těmito lidmi žádný vztah nad rámec doručení. Je to zase modul 1: příjemce je zákazník partnera a partner je autoritou pro to, kdo to je. A je to kapitola 5: osobní údaje, které přistanou na jednom místě, navázané na jedno doručení, se mnohem snáz chrání, uchovávají a mažou. A obstojí to i před normálními formami z kapitoly 2: údaje o příjemci jsou jedna k jedné s doručením, takže patří na něj. Samostatný podřízený záznam příjemce by ušetřil pár opakovaných hodnot za cenu dalšího objektu, dalšího vztahu a jeho režie, a víc by ušetřil jen tehdy, kdybychom stejnou osobu brali jako jednu napříč maloobchodními partnery, což dělat nebudeme. Doručení tedy nese příjemce, s Retail Partner Customer ID jako cestou zpět do partnerova vlastního systému.

Kliknutím zvětšíte

Sjednotil bych příjemce napříč partnery?

John Smith, 123 Main Street, se objeví v manifestu od Redrock i od Brightwave. Nejspíš stejná osoba. Má je Steve Trucking sjednotit? Ne, záměrně ne. Sjednocení příjemců napříč maloobchodními partnery by porušilo S2: partner nikdy nesmí vidět příjemce jiného partnera a sjednocená identita je přesně ten most, kudy to unikne. Je to postoj této kapitoly v praxi: kde je smíchání drahé, párujte méně, a tady je smíchání velmi drahé.

Pokud maloobchodní partner později bude chtít rozpoznávat opakované příjemce v rámci svých vlastních doručení, je to práce pro nástroj na rozpoznávání identity, jako je ten v Data 360, omezený na toho partnera: mapa ve stylu registru, ne osobní účet, a nikdy napříč partnery. Mapa toho, kdo je kdo, nedává vlastnictví a nedává ani přístup.

Co zůstane v orgu a co ne

Kapitola 3 se ptala, kde by data měla žít. Tady odpovídají nuly:

• Aktuální stav žije na Service Appointment a Work Order. Historie změn stavu, asi 8 milionů ročně a přibývá, v core orgu žít nemusí. Každá změna se zveřejní jako událost a uchová v datovém skladu, Snowflake. Org drží aktuální stav; historie je pořád k dispozici pro servis, provoz a analytiku, jen ne v provozní databázi.
• Fotky (čtyři až pět milionů ročně, některé ukazují lidi nebo interiér domova) žijí mimo core v úložišti postaveném pro takový objem, nahrávané přímo z aplikace posádky. Org si drží jen to, co potřebuje: malý indexový záznam na fotku, nebo jen počet a příznak „povinné fotky instalace jsou kompletní“. Dávám přednost lehčí možnosti: držte org štíhlý a nechte úložiště fotek vlastnit jeho index i uchovávání.
• Údaje z GPS (200 000 denně) zůstávají ve FleetLink a jdou do Snowflake; org potřebuje jen poslední polohu pro stránku sledování a dispečerovu mapu.
• Osm let historie z RouteDesk (asi 5 milionů doručení) jde do datového skladu nebo archivu, dosažitelná kvůli reklamacím. Co, pokud vůbec něco, přijde do orgu, je migrační rozhodnutí pro část 2.

Kliknutím zvětšíte

Kontrolní bod 1: co bych navrhl já. Stejná místa jako v krajině z kapitoly 4 (Systémová krajina Steve Trucking), bez přepisování a bez tabulky.

Kdo co vidí a kdo potřebuje licenci

• Maloobchodní partneři vidí jen svá vlastní doručení (S2). Každý Work Order nese svého maloobchodního partnera; uživatelé portálu vidí doručení svého partnera a vedoucí DC jen doručení svého DC.
• Uživatelé partnerů potřebují licenci portálu, která podporuje pravidla sdílení a role: Customer Community Plus nebo Partner Community. Stadionová sedadla z kapitoly 3: nejlevnější sedadla nedostanou sdílení, které tento návrh potřebuje. Obě licence potřebují role pro externí uživatele a Salesforce varuje, že víc rolí org zpomaluje (Experience Cloud User Licenses (otevře se v nové kartě)). Role na partnera a na DC je v pořádku; role pro každou prodejnu ne.

Ke zkoušce. Vězte, které externí licence nesou standardní sdílení: Customer Community Plus a Partner Community (s rolemi pro externí uživatele), ne Customer Community, která používá sady sdílení.

• Příjemci žádnou licenci nepotřebují. Stránka sledování ukazuje jedno doručení přes odkaz s tokenem, jehož platnost vyprší (S3), ne přes přihlášení.
• Hlídejte skew. Statisíce záznamů Work Order ročně, které ukazují na tři nebo čtyři účty partnerů, jsou account data skew. Jednou možností je podřízený účet pro každé DC pod každým partnerem, což podřízené záznamy rozprostře do devíti nebo více větví; archivace dokončených doručení po uplynutí lhůty pro reklamace udrží počet aktivních podřízených záznamů na rodiče nízko. Do toho se pustí část 2.

Co bych nedělal

Nevytvořil bych osobní účet pro každého příjemce jen proto, že je příjemce jednotlivec. Nepověsil bych milion kontaktů na tři účty. Nepostavil bych vlastní objekt Delivery vedle Work Order z Field Service. Nesjednotil bych příjemce napříč partnery. Nedal bych miliony fotek ani údajů z GPS do úložiště core. A nenazval bych sjednoceného příjemce zlatým záznamem, pokud bychom skutečně neudělali rozhodnutí o správě kmenových dat.

Co zůstává otevřené

Část 1 postavila kostru; část 2 ji otestuje. Pravítko LDV ve třetím roce (Work Order, Service Appointment i řádkové položky budou do dvou až tří let v pásmu velkých objemů), návrh dotazů pro zobrazení seznamů omezená na partnera, tři příchozí integrace a tři stavové toky, migrace z RouteDesk, transakce v den doručení a návrh zabezpečení za portálem. Steve Trucking se také bude měnit. Tento návrh si nechte; vrátíte se k němu.

Co tady rozhoduje architekt

• Které standardní objekty nesou jádro (tady ty z Field Service) a které vlastní objekty jsou opravdu opodstatněné (tady jeden).
• Klíč, který páruje každý řádek objednávky partnera s doručením, a proč patří partnerovi.
• Čím je příjemce, podle vztahu, který s ním Steve Trucking skutečně má.
• Zda sjednocovat identity a kde je smíchání příliš drahé na to, abychom riskovali.
• Co zůstane v orgu, co žije mimo core a na kterých licencích návrh závisí.

K prozkoumání

• Zadání a úkoly Steve Trucking (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (otevře se v nové kartě) Considerations for Object Relationships (otevře se v nové kartě) a Experience Cloud User Licenses (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Developers, Parent-Child Data Skew (otevře se v nové kartě), jak je citováno v kapitole 3.