Navrhněte fyzický model v Salesforce

🌐 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 10 z 10 kapitoly Datová architektura Salesforce, kapitoly 3 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Udržení konzistence dat · Další: studijní průvodce kapitolou, pak další kapitola, Porozumění podnikovým datům

Otázka, na kterou tento modul odpovídá: Jak z našeho logického modelu udělat architekturu v Salesforce?

Tato kapitola byla jedním dlouhým argumentem, že platforma má tvar: standardní a vlastní objekty, místa, kde mohou data žít, typy polí, vztahy, vlastnictví, licence, pravidla konzistence, úložiště a měřítko. Každé z toho může změnit, jak se postaví logický model z kapitoly 2. Teď to dejme dohromady na jednom výřezu Steve Trucking.

Jeden výřez, ne celá firma. Chyba, kterou u architektů vídám, je snažit se vyřešit celý podnik jedním diagramem. Chci něco, o čem můžeme uvažovat: maloobchodní partner pošle manifest, Steve Trucking doručí, co na něm je, a my si o každém doručení uchováme, co potřebujeme. Pak děláme fyzická rozhodnutí jedno po druhém. Úplný návrh je kontrolním bodem části 1.

Začněte tím, co už víme

Kapitola 2 udělala konceptuální práci: maloobchodní partner, příjemce, manifest, doručení, položka doručení, druh zastávky, posádka, kamion, distribuční centrum, fotky. Pojmenovali jsme vztahy a ptali se, co znamenají. To opakovat nebudu. Otázka teď zní, jak tyto pojmy žijí v Salesforce. Jeden fakt ze zadání je důležitý hned: Steve Trucking už provozuje Field Service pro schůzky, posádky a mobilní aplikaci.

Maloobchodní partner: nevymýšlejte účet

Maloobchodní partner je firma, pro kterou Steve Trucking pracuje. Salesforce už má objekt navržený pro firmy: Account. Čistý soulad. Žádný Retail_Partner__c jen proto, že byznys říká „partner“. Je to Account, s typem záznamu Retail Partner, který ho odliší od jiných organizací, a s ním přicházejí smlouvy, případy, kontakty pro vedoucí DC a přístup na portál pro tyto kontakty. Snadné rozhodnutí. Ne všechna jsou takové.

Číslo objednávky partnera není naše identifikace

Každý maloobchodní partner posílá vlastní reference. Objednávka jednoho partnera vypadá jako 8843119, jiného jako A-984732. Na těch číslech záleží, ale čí jsou? Partnerova. Salesforce má vlastní ID záznamu a partner má referenci, kterou používá, když s námi mluví. Obojí může existovat; to je „jedna věc, několik identifikátorů“ z kapitoly 2.

Reference partnera se tedy stane External ID, které integrace používá k párování aktualizací. A protože dva partneři mohou použít stejné číslo, identifikace je partner plus reference, ne reference sama. Nedělejte z čísla partnera univerzální identifikaci doručení jen proto, že přišlo první, a nenuťte integraci prohledávat textové pole pokaždé, když potřebuje najít záznam.

Doručení: dívejte se na mateřskou loď

Tady je lákavé vytvořit Delivery__c. Byznys řekl „doručení“, takže potřebujeme objekt Delivery. Přesně tohle nechci, abyste udělali jako první. Dívejte se na mateřskou loď, jako jsme to dělali v modulu 2. Co už Salesforce má pro práci prováděnou na určitém místě, s životním cyklem, položkami, plánováním a posádkou v terénu? Work Order z Field Service: Salesforce ho popisuje jako práci v terénu, která se má pro zákazníka provést (WorkOrder (otevře se v nové kartě)). Naplánovaná návštěva a její časové okno je Service Appointment, a to plánuje dispečink a ukazuje aplikace posádky.

Takže Doručení → Work Order. Ne proto, že by slova seděla; nesedí. Protože chování odpovídá schopnosti platformy, za kterou už platíme a kterou chceme používat. Standardní objekt nemusí sdílet obchodní slovník. Musí pojem správně reprezentovat.

Kliknutím zvětšíte

Krok 1 ze 4: mateřská loď. Každá karta je obchodní pojem a pod ním jeho objekt Salesforce.

Standardní objekty ale přicházejí se zavazadly

Druhá polovina: Work Order není zadarmo. Přináší licence Field Service, vlastní vztahy, chování zabezpečení, povinná pole, automatizaci i životní cyklus a jiné části platformy očekávají, že se bude chovat určitým způsobem. Volíme ho proto, že soulad je čistý, a používáme to, co je kolem něj postavené. Kdyby Steve Trucking z Field Service nechtěl nic a model by na každém kroku bojoval s procesem, zvážil bych to znovu. Architektura je soulad, ne popisek.

Položky doručení: následujte model

Jakmile je doručení Work Order, podívejte se na zbytek toho modelu dřív, než cokoli vymyslíte. Work Order Line Item je dílčí úkol pracovního příkazu (WorkOrderLineItem (otevře se v nové kartě)): lednička, instalace, odvoz. Takže Položka doručení → Work Order Line Item. Všimněte si, že první rozhodnutí ovlivnilo druhé. Nevybíráme objekt pro každou entitu zvlášť. Přijměte model a pochopte jeho zbytek dřív, než kolem něj začnete stavět vlastní struktury.

Jaký druh zastávky to je?

Ve Steve Trucking je zastávka jen doručení, doručení s instalací, nebo doručení s odvozem a každý druh má vlastní dobu trvání, dovednosti posádky a kontrolní seznam instalace. V kapitole 2 jsme rozhodli, že je to entita, ne popisek. Field Service ji už má: Work Type, šablonu pro typ práce, kterou lze použít na pracovní příkazy a jejich řádkové položky (WorkType (otevře se v nové kartě)). Takže Druh zastávky → Work Type. Zase ne proto, že existuje něco jménem Work Type, ale protože pojem a chování spolu ladí.

Kliknutím zvětšíte

Krok 2 ze 4: následujte model. Řádkové položky a Work Type přicházejí s Work Order.

Manifest: teď chci vlastní objekt

Existuje standardní objekt pro „seznam partnera na úterý pro DC ve Phoenixu“? Ne tak docela a nebudu ho cpát do nesouvisejícího objektu jen proto, abychom mohli říct, že jsme zůstali u standardu. Manifest → Manifest__c. Je to jednotka příjmu: odkud přišel (soubor, dávka z API), kdy, jeho stav a součty a, když ho partner v den doručení pošle znovu, co se porovnává. Z každého řádku manifestu se stane Work Order navázaný zpět na něj.

Vlastní objekt není selhání. Je to to, co nám platforma dává, když pojem nemá čistý standardní domov. Chybou není vytvořit vlastní objekt; chybou je vytvořit ho, aniž bychom zkontrolovali, jestli platforma ten pojem už nemá.

Kliknutím zvětšíte

Krok 3 ze 4: jediný vlastní objekt, tam, kde nesedí žádný standardní.

Fotky: to, že je Salesforce dokáže uložit, neznamená, že by měl

„Potřebujeme fotky z doručení v Salesforce.“ Co znamená „v Salesforce“? Uživatelé je potřebují ze Salesforce vidět, ano. Znamená to, že soubory obrázků musí žít v úložišti core? Ne nutně. Spočítejte nuly: asi čtyři fotky na doručení, víc u instalací, při milionu doručení ročně, to jsou čtyři až pět milionů fotek ročně, a doručení rostou o 30 % ročně.

Můj výchozí postoj tedy: nedělejte z core orgu obří úložiště fotek jen proto, že uživatelé potřebují k fotkám přístup. Soubory patří do úložiště postaveného pro takový objem, mimo core, a Salesforce si drží, co potřebuje, aby je našel a ukázal: odkaz, počet nebo malý indexový záznam na fotku a příznak, že povinné fotky instalace jsou kompletní. Přístup k datům a místo, kde data fyzicky žijí, jsou dvě různé otázky. To se vrací modul 4.

Pole: udělejte význam viditelným

Work Order potřebuje pole: referenci partnera, okno doručení, skutečný čas doručení, stav, poznámky jako „kód brány“ nebo „pes na zahradě“. Nebudu z toho dělat katalog polí; to udělal modul 6. U každého projděte otázky: co znamená, kdo ho vlastní, jestli se mění, jestli je to identifikátor, řízený slovník, uložené, nebo odvozené, citlivé. Reference partnera je External ID, takže její jedinečnost je součástí integračního kontraktu, ne jen zaškrtávací políčko. Skutečný čas doručení je okamžik, tedy Date/Time. Stav řídí chování, takže řízený seznam, nikdy volný text. A poznámky k doručení o něčím domově jsou osobní údaje, takže se klasifikují. Každé pole vede zpět k významu.

Vztahy: nespojujte jen krabice

Account k Work Order, Work Order k jeho řádkovým položkám, Manifest k Work Order, Work Type popisující zastávku. Pak otázky z modulu 7 pro každou čáru: může podřízený záznam existovat sám, kdo ho vlastní, dědí se přístup, může se přesouvat, co se stane při smazání, kolik podřízených záznamů se může nahromadit? Každý Work Order pod hrstkou účtů maloobchodních partnerů znamená statisíce podřízených záznamů na nadřazený: otázka skew, na kterou odpovíme v části 2. A u standardních vztahů Field Service zkontrolujte, jak je Salesforce už postavil, místo předpokladu, že odpovídají tomu, co bychom navrhli my. Když přijmete standardní model, přijímáte rozhodnutí, která v něm Salesforce udělal. Pochopte je dřív, než na nich začnete stavět.

Vlastnictví a příjemce: nenechte rozhodnout výchozí nastavení

Dvě rozhodnutí, která by za nás výchozí nastavení ochotně udělalo.

Kdo vlastní doručení? Na to jsme odpověděli v modulu 8 a přenáší se to rovnou na Work Order: vlastnictví tu neřídí ničí přístup, takže integrační uživatel vlastní Work Order, které vytvoří. Dispečeři vidí ty ze svého distribučního centra, posádky ty ze svých tras a každý maloobchodní partner vidí ty své přes portál, všechno přes sdílení, ne přes vlastnictví. Integrační uživatel nemá roli a zůstává mimo veřejné skupiny, které používají naše pravidla sdílení, protože při 3 300 denně překročí 10 000 záznamů za tři dny. A zapíšeme si, co se stane, když se ten uživatel někdy nahradí.

Čím je příjemce? Kontaktem? Osobním účtem? Něčím drženým jen na doručení? Záleží na tom, jestli má Steve Trucking s těmito lidmi vůbec vztah (jsou to zákazníci maloobchodních partnerů), jestli jeden partner smí někdy vidět příjemce jiného, jak dlouho se smějí uchovávat jejich osobní údaje, a na měřítku: asi milion nových příjemců ročně. To všechno zatím nemáme, a to je v pořádku. Někdy je správnou odpovědí zatím nevíme dost. Zapište si otázku a jděte pro informace; nepohřbívejte nejistotu ve vlastním objektu. Odpovíme na ni u kontrolního bodu části 1, až nám kapitoly 4 až 6 dají obraz podniku a kmenových dat.

Konzistence: chraňte model na správné vrstvě

Platí žebříček z modulu 9: reference partnera je External ID, jedinečné, takže znovu odeslaný manifest provede upsert, místo aby vytvořil duplicity; stav je omezený seznam; skutečný čas doručení je povinný, až když stav říká Delivered; zastávka s instalací se nedá uzavřít bez kontrolního seznamu a fotek. Ne jedno obří flow. Každé pravidlo na vlastní příčce.

Kde žije každý kus

Ještě jeden průchod výřezem, s otázkou z modulu 4: kde žije každý kus dat? V mé prezentaci pro třídu je to jeden slajd, logické proti fyzickému: logické entity z kapitoly 2 a kam každá fyzicky přistane: na core, jako sObject (__c, pokud je vlastní) nebo big object (__b), nebo mimo core, jako externí objekt (__x) nebo data, která do Salesforce nikdy nepřijdou.

• Na core, s každodenní prací: Account, záznamy Work Order a jejich řádkové položky, Service Appointment, Work Type, Manifest__c.
• Na core, archivované: doručení starší než tři roky se přesouvají do Delivery History, big objectu, pořád k dispozici kvůli reklamacím, venku v kůlně.
• Odkazovaná: vlastní podrobnosti objednávky maloobchodního partnera zůstávají v systému partnera; referenci partnera si držíme jako External ID a ke zbytku se dostaneme přes externí objekt nebo integraci, když to někdo potřebuje.
• Mimo core: fotky, v úložišti postaveném pro miliony obrázků, s odkazem z Work Order.

To je fyzický model: nejen jaký objekt, ale jaký domov.

Teď se podívejte na celý výřez

• Maloobchodní partner → Account, s typem záznamu Retail Partner; vedoucí DC jako kontakty.
• Doručení → Work Order z Field Service, plánované přes Service Appointment.
• Položka doručení → Work Order Line Item.
• Druh zastávky → Work Type.
• Manifest → vlastní Manifest__c.
• Reference partnera → External ID na Work Order, jedinečné pro každého partnera.
• Fotky → uložené mimo core; Salesforce si drží odkaz a příznak úplnosti.
• Historie doručení → po třech letech archivovaná do big objectu.
• Vlastnictví → integrační uživatel, s přístupem přes sdílení (modul 8).
• Příjemce → otevřené, pro kontrolní bod části 1.

Kliknutím zvětšíte

Krok 4 ze 4: celý výřez, na core, archivovaný a mimo core. Každá čára je lookup: Salesforce postavil Field Service na lookupech a my s ním přijímáme jeho rozhodnutí.

Diagram není architektura

Můžu vám ten diagram podat, a nestačí to. Architektura je úvaha za ním. Proč Account? Firma s čistým souladem. Proč Work Order, a ne Delivery__c? Doručení se chová jako práce v terénu a Field Service už je zavedené. Proč vlastní Manifest? Žádný čistý standardní domov. Proč fotky nejsou prostě Files? Objem a ekonomika úložiště. Proč External ID? Jiný systém potřebuje stabilní identifikaci přes hranici. Proč vlastní Work Order integrační uživatel? Vlastnictví tu neřídí přístup a díky tomu je auditní stopa poctivá. Proč je příjemce pořád otevřený? Ještě jsme neodpověděli na dost otázek. Čáry jsou výstup; vytvořila je rozhodnutí.

Tady je tedy návyk, se kterým chci, abyste z kapitoly 3 odešli. Ukažte na cokoli ve fyzickém modelu a zeptejte se proč? Proč tento objekt, tento typ, tento vztah, tento vlastník, toto místo, toto pravidlo? Odpověď byste měli umět vystopovat zpět: od konfigurace k fyzickému modelu, k logickému modelu, k obchodnímu požadavku. Pokud to neumíte, někdo navrhoval ze Setupu.

A všimli jste si čísel, která jsme zatím úplně nepropočítali: doručení na partnera, řádkové položky, fotky, uchovávání, archivace. Dobře. Než návrh zafixujete, ptejte se na počet nul: model, který nádherně funguje s padesáti tisíci záznamy, se může chovat úplně jinak s pěti sty miliony. To je část 2.

Nad rámec zkoušky: co mění AI. Dejte AI zadání Steve Trucking a za pár sekund vytvoří schéma: Account, Work Order, vlastní objekty, pole, dokonce metadata pro nasazení. To je fantastický urychlovač, a není to revize. Práce architekta se posouvá ke kontrole mapování a jejich důsledků: soulad, licence, vlastnictví, životní cyklus, měřítko, identifikace, zabezpečení a co zůstává mimo platformu. AI je raketový urychlovač; neřekne vám, jestli míříte správným směrem.

Co tady rozhoduje architekt

• Jak se každý obchodní pojem mapuje na Salesforce: standardní objekt, vlastní objekt, nebo něco mimo core.
• Které identifikátory, pole a vztahy implementují obchodní význam, aniž by ho potichu měnily.
• Jaké chování platformy a licence přicházejí se standardním modelem, který přijmete.
• Která rozhodnutí o vlastnictví, životním cyklu, konzistenci, úložišti a měřítku musí padnout dřív, než je návrh hotový.
• Které otázky zůstávají výslovně otevřené, místo aby se schovaly za libovolnou implementační volbu.

Na začátku této kapitoly jsme se ptali, jak by měl model žít v Salesforce. To je datová architektura Salesforce: ne vytváření objektů, ne učení Setupu nazpaměť, ne kreslení hezčích krabic, ale záměrné přizpůsobení obchodního modelu tvaru platformy. Každá struktura je závazek. Dělejte ty, které umíte vysvětlit.

K prozkoumání

• Salesforce Developers, Object Reference: WorkOrder (otevře se v nové kartě), WorkOrderLineItem (otevře se v nové kartě) a WorkType (otevře se v nové kartě), ověřeno 2026-10-17.
• Zadání Steve Trucking.