Vztahy mají důsledky

🌐 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 7 z 10 kapitoly Datová architektura Salesforce, kapitoly 3 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: I pole jsou architektura · Další: Vlastnictví a životní cyklus

Otázka, na kterou tento modul odpovídá: Co doopravdy volím, když propojím dva objekty Salesforce?

Nakreslit vztah je snadné. V kapitole 2 jsme kreslili čáry a pojmenovávali je: maloobchodní partner posílá mnoho manifestů, doručení nese mnoho položek, posádky a kamiony se potkávají v přiřazení posádky. Mluvili jsme o kardinalitě, volitelnosti a historii. Teď ty čáry implementujeme v Salesforce a čára na diagramu začne nést mnohem větší váhu.

Když volím typ vztahu v Salesforce, neříkám jen tyto dva záznamy jsou propojené. Možná také rozhoduji, kdo vlastní podřízený záznam, jestli může existovat bez nadřazeného, kdo ho vidí, co se stane, když se nadřazený smaže, jestli se může přesunout k jinému nadřazenému, jestli ho můžu shrnout na nadřazený záznam a co se stane, když budou podřízených záznamů statisíce. Vztah není jen čára. Nese chování.

Začněte obchodním vztahem

Než přijde lookup nebo master-detail, vraťte se k byznysu. Vezměte doručení a jeho položky doručení, ledničku, instalaci, odvoz. Může položka existovat bez svého doručení? Ne. Když se doručení smaže, mají jít jeho položky s ním? Ano. Potřebují položky vlastního vlastníka nebo vlastní zabezpečení? Ne tak docela. Měl by někdo přesunout položku z jednoho doručení na jiné? Snad ne omylem.

Teď vezměte doručení a trasu, na které je. Doručení existuje dřív, než je na trase, může se přesunout na jinou trasu, když se plán změní, a smazání trasy by nikdy nemělo smazat doručení na ní. Dvě čáry jedna k mnoha, které na diagramu vypadají stejně, s úplně odlišným chováním. Všimněte si, že jsme pořád neřekli „lookup“ ani „master-detail“. Nejdřív popište chování. Konfigurace ho implementuje.

Typy vztahů

Otevřete obrazovku New Field a Salesforce vám nabídne hrstku typů vztahů (Object Relationships Overview (otevře se v nové kartě)):

• Lookup: propojuje dva objekty. Chleba s máslem vztahů v Salesforce.
• Master-detail: vazba nadřazený–podřízený, kde nadřazený záznam řídí podřízený.
• Mnoho k mnoha: není to samostatný typ pole, ale vzor: spojovací objekt Salesforce (Salesforce Junction Object), vlastní objekt se dvěma vztahy master-detail.
• Vztah sám na sebe (self-relationship): lookup z objektu na sebe samý.
• Hierarchický (hierarchical): zvláštní lookup, který existuje jen na objektu User, třeba manažer uživatele.
• Externí lookup a nepřímý lookup (external lookup, indirect lookup): vztahy k externím objektům a od nich, k objektům __x z modulu 4. Externí lookup ukazuje na nadřazený externí objekt; nepřímý lookup ukazuje z externího objektu na standardní nebo vlastní objekt, párovaný podle jedinečného External ID.

Většina vašeho času na návrhu jde do prvních tří. Vezměme je jeden po druhém.

Lookup: tyto záznamy jsou propojené

Lookup říká: tento záznam je přidružený k tamtomu záznamu. Podřízený záznam si ponechává vlastní existenci, vlastního vlastníka a vlastní život. Doručení ukazuje na svou trasu. Když se trasa zruší, doručení nezmizí; vrátí se k novému naplánování.

Je to legrační: pole lookup jde na podřízený záznam, ale něco dostane i nadřazený, seznam souvisejících záznamů (related list) svých podřízených. Když ho tedy vytváříte, pojmenujte oba konce. Related List Label je to, co lidé vidí na nadřazeném záznamu, a Child Relationship Name je to, co používají vývojáři a integrace, aby se dostali od nadřazeného k podřízeným. Nepřijímejte výchozí hodnoty.

Lookup může být povinný, nebo volitelný. Když je volitelný, rozhodujete, co se stane, když se smaže záznam, na který ukazuje, a jsou tři možnosti (Considerations for Object Relationships (otevře se v nové kartě)):

• Clear the value of this field, výchozí volba. Podřízený záznam zůstane, s prázdným lookupem.
• Don’t allow deletion záznamu lookupu. Zkuste smazat trasu a Salesforce řekne ne: je součástí vztahu.
• Delete this record also, kaskádové mazání, jako u master-detail. Nabízí se jen u vlastního lookupu na vlastním objektu, je ve výchozím stavu vypnuté a Salesforce ho musí pro váš org zapnout, protože kaskádové mazání obchází zabezpečení a sdílení: uživatelé mohou smazat záznamy, které ani neviděli.

To je rozhodnutí o životním cyklu schované v obrazovce Setupu.

Filtry lookupu (lookup filters) zužují, co uživatel může vybrat. Řekněme, že doručení má lookup Installer na Contact a instalatéři jsou jeden typ záznamu kontaktu z mnoha. Filtr lookupu ukáže jen instalatéry a může filtrovat podle aktuálního záznamu, podle vyhledávaného záznamu i podle uživatele: jeho profilu, role nebo oprávnění (Lookup Filters (otevře se v nové kartě)). Je to levný způsob, jak udržet lookup poctivý.

Master-detail: tento podřízený záznam patří k tomu nadřazenému

Master-detail dělá mnohem silnější tvrzení. Ve třídě tomu říkám velmi těsná vazba. Nemůžete mít podřízený záznam bez hlavního; pole hlavního záznamu je povinné. Podřízený záznam ztrácí vlastní pole Owner a dědí vlastníka svého nadřazeného. Pro podřízený záznam neexistuje samostatná tabulka sdílení, takže podřízený záznam nemůžete sdílet samostatně; dědí sdílení svého nadřazeného. Proto podřízený objekt nemůže mít pravidla sdílení, ruční sdílení ani fronty: všechny potřebují pole Owner (Object Relationships Overview (otevře se v nové kartě)). V Setupu jeho nastavení sdílení zní Controlled by Parent. A přímo na poli master-detail volíte Sharing Setting: jestli uživatel potřebuje k hlavnímu záznamu přístup Read Only, nebo Read/Write, aby mohl vytvářet, upravovat nebo mazat jeho podřízené záznamy. Smazání hlavního záznamu smaže jeho podřízené. A hlavní záznam dostane souhrnná pole (roll-up summary).

Pokud je tedy položka doručení podřízeným záznamem doručení, říkám: tato položka patří k tomuto doručení celý svůj život. To je otázka, na kterou chci odpověď dřív, než kdokoli v Setupu vybere Master-Detail Relationship.

Otázka mazání

Tady je můj oblíbený způsob, jak zjistit, jestli jsme to promysleli: co se má stát s podřízenými záznamy, když někdo smaže nadřazený? Všem začne být nepříjemně. Dobře. Teď děláme architekturu.

Maloobchodní partner má statisíce historických doručení. Někdo partnera smaže. Mají doručení zmizet? Téměř jistě ne: závisí na nich reklamace, fakturace i historie. Možná by smazání partnera nemělo být vůbec povoleno a partner by se měl místo toho deaktivovat. U master-detail se smazání hlavního záznamu kaskádovitě přenese na podřízené záznamy a jejich podřízené; obnovení hlavního záznamu je vrátí (Considerations for Object Relationships (otevře se v nové kartě)). Když tedy někdo řekne „master-detail nám dá souhrnná pole“, moje odpověď zní: skvělé. S čím dalším jste právě souhlasili?

Vlastnictví se veze s sebou

U lookupu může mít podřízený záznam vlastního vlastníka. U master-detail nemůže; přístup se řídí hlavním záznamem. To je přesně správně, pokud je podřízený záznam opravdu částí nadřazeného. Pokud ale podřízený záznam potřebuje vlastního vlastníka, vlastní sdílení nebo vlastní životní cyklus, model vám říká, že master-detail je špatná volba. Další modul jde do vlastnictví hlouběji a kurz Sharing and Visibility ještě dál. Prozatím: návrh vztahů a návrh zabezpečení nejsou oddělené rozhovory. Datový model tvaruje model zabezpečení dřív, než kdokoli napíše pravidlo sdílení.

Povinný nadřazený záznam, nebo volitelný?

Může podřízený záznam existovat dřív, než známe jeho nadřazený? Záleží na tom víc, než zní. Pokud doručení přicházejí na manifestu večer předem a trasy se stavějí až potom, povinná trasa na doručení by znamenala, že plánování tras musí proběhnout dřív, než se záznam vůbec dá vytvořit. Fyzický vztah musí podporovat skutečný životní cyklus. Vztahy proto nenavrhuji jen ze statického diagramu. Chci vědět: jak se rodí, mohou existovat samy, mohou se přesouvat a jak umírají?

Může podřízený záznam změnit nadřazený?

Ve výchozím stavu se podřízený záznam master-detail nedá přesunout k jinému nadřazenému. Můžete to povolit zaškrtnutím Allow reparenting u vztahu (Considerations for Object Relationships (otevře se v nové kartě)). Můj instinkt je konzervativní: pokud byznys říká, že podřízený záznam patří celý život k jednomu nadřazenému, nedělám jeho přesun snadným. Přesun položky z jednoho doručení na jiné by měl být záměrná obchodní událost, ne úprava pole. Zase: nastavení není architektura. Architekturou je pravidlo životního cyklu a nastavení ho implementuje.

Dvě další věci, které týmy dostihnou později. Na objektu, který už má data, nemůžete vytvořit vztah master-detail; vytvoříte lookup, vyplníte ho na každém záznamu a pak ho převedete. A zpět na lookup ho můžete převést, jen když na hlavním záznamu nejsou souhrnná pole. Hlídejte i to, co převod dělá se zabezpečením: převod lookupu na master-detail nastaví sdílení podřízeného záznamu na Controlled by Parent a převod master-detail zpět na lookup nastaví výchozí nastavení celé organizace pro podřízený záznam na Public Read/Write (Considerations for Object Relationships (otevře se v nové kartě)). Záznamy, které byly včera soukromé, jsou dnes otevřené, dokud si toho někdo nevšimne. Rozhodněte brzy.

Souhrnná pole jsou užitečná, ale nejsou zadarmo

Souhrnná pole mám rád. Spočítat položky na doručení, sečíst částky řádků na faktuře, najít poslední datum: nativně, bez kódu. Pole master-detail jde na podřízený záznam, ale souhrnné pole jde na nadřazený. Mají ale drobné písmo (Roll-Up Summary Field (otevře se v nové kartě)):

• Výpočet souhrnných hodnot po určitých změnách (nové souhrnné pole, změněný vzorec, na kterém závisí, vynucený přepočet) může trvat až 30 minut, podle toho, kolika záznamů se týká. Viděl jsem lidi divit se, proč se číslo na nadřazeném záznamu ještě nezměnilo.
• Nedokážou shrnout všechno. Automatické číslo nemůže být polem, které agregujete. A souhrnné pole může shrnout pole se vzorcem, jen pokud ten vzorec nesahá na jiný objekt a nepoužívá funkci, která se mění sama, jako NOW() nebo TODAY(). Vzorec „dní po splatnosti“ postavený na TODAY() se mění každou noc, aniž by kdokoli uložil záznam, takže souhrnné pole nemá z čeho přepočítávat. Takové číslo potřebuje plánované flow, nebo sestavu.
• I filtr má limity: žádná dlouhá textová oblast, výběrový seznam s více hodnotami, Description, systémová pole jako Last Activity, vzorce napříč objekty ani pole lookup.
• Souhrnná pole nejsou na stránkách úprav, takže ověřovací pravidlo ho může použít, ale nemůže tam ukázat svou chybu.

A rozhodnutí neotáčejte. Neříkejte: „Potřebujeme souhrnné pole, takže to musí být master-detail.“ Řekněte: „Tento podřízený záznam opravdu patří k tomuto nadřazenému, vlastnictví a životní cyklus sedí a jednou z výhod jsou nativní souhrnná pole.“ Pokud sémantika nesedí, vyřešte výpočet jinak. Nedeformujte datový model kvůli funkci.

Jak tedy jinak? Souhrnné pole si postavíte sami: pole na nadřazeném záznamu, které drží vypočtenou hodnotu, a automatizaci, která ho udržuje aktuální. Řekněme, že maloobchodní partner je lookup z doručení, jak má být, a byznys chce na partnerovi Open Deliveries. Přidejte na partnera číselné pole Open Deliveries. Pak flow spouštěné záznamem (record-triggered flow), nebo trigger v Apexu, když objem nebo logika vyžadují kód, ho přepočítá, kdykoli se doručení změní. Funguje to přes lookup, může to filtrovat podle čehokoli a může to používat data a vzorce, které nativní souhrnné pole použít nemůže.

Teď je to ale na vás, abyste to udělali správně, a tady se to kazí. Automatizace musí proběhnout při každé změně, na které záleží: nový podřízený záznam, upravený, smazaný, obnovený a podřízený záznam přesunutý k jinému nadřazenému, což znamená přepočítat starý i nový nadřazený záznam. Musí zvládnout nahrávání dat po 200 záznamech najednou, aniž by narazila na limity. Přepočítávejte znovu, místo přičítání a odčítání, aby jedna zmeškaná událost nenechala číslo navždy špatně. Naplánujte způsob, jak přepočítat všechno, pro první nahrání i pro den, kdy se to rozejde. A pamatujte, že každé uložení podřízeného záznamu teď aktualizuje nadřazený, takže nadřazený záznam s tisíci podřízenými přináší zpět zamykání, které za chvíli uvidíme. Nativní souhrnné pole to všechno udělá za vás; vlastní je malý kus softwaru, který vlastníte.

Tři úrovně do hloubky: vrstvení master-detail

Platforma má tvar a master-detail má dva jeho rozměry. Prvním je hloubka.

Master-detail můžete vrstvit tři vlastní podřízené úrovně do hloubky, a to je dno (Considerations for Object Relationships (otevře se v nové kartě)). Ve třídě to kreslím jako účet s objednávkou (jedna), objednávku s jejími položkami (dvě) a položky s jejich podrobnostmi (tři), a pak se pokusím přidat čtvrtou a Salesforce mi to nedovolí. Ve Steve Trucking by to mohlo vypadat takhle: Doručení je hlavní záznam; jeho Položky doručení jsou první úroveň; Úkoly instalace položky druhá; a Kroky úkolu u každého úkolu třetí. Čtvrtá úroveň, třeba Poznámka ke kroku, musí být lookup.

Kliknutím zvětšíte

S vrstvením přichází pár pravidel:

• Standardní objekty nemohou být na podřízené straně vlastního objektu. Vlastní objekt může být podřízený Account; Account nemůže být podřízený vašemu objektu.
• Objekt se může ve víceúrovňovém vrstvení objevit jen jednou. Salesforce nechce, abyste se zacyklili: podřízený záznam nižší úrovně nemůže být zároveň hlavním záznamem svého hlavního záznamu.
• Hlavní záznam nemůže shrnout spodní úroveň přímo. Pokud chce doručení počet kroků úkolu, úkol instalace shrne své kroky, položka doručení shrne ta shrnutí a doručení shrne položky: jedna úroveň po druhé.
• Vlastnictví a sdílení přicházejí shora. Každá úroveň dědí vlastníka a přístup hlavního záznamu.
• Smazání hlavního záznamu smaže všechno pod ním a jeho obnovení všechno vrátí.

Tři úrovně obvykle stačí. Pokud váš návrh pořád chce čtvrtou, zeptejte se, jestli každá úroveň opravdu patří celý život k té nad ní. A pamatujte, že si můžete vybrat, který článek řetězec přeruší. Čtvrtá úroveň nemusí být tím lookupem: možná úkol instalace doopravdy nepatří ke své položce doručení, plánuje a přiřazuje se samostatně, takže se z té vazby stane lookup a úkol instalace teď začíná nový řetězec s krokem úkolu a poznámkou ke kroku pod sebou. Vyberte vazbu, kde má podřízený záznam opravdu vlastní život, a z té udělejte lookup.

Kliknutím zvětšíte

Teď má úkol instalace vlastního vlastníka a vlastní sdílení, doručení se dá smazat, aniž by s sebou vzalo své úkoly instalace, a úkol instalace může mít pod sebou další dvě úrovně. To je ta výměna: řetězec je kratší a život úkolu instalace patří jemu.

Dva rodiče do šířky: spojovací objekt Salesforce

Nejdřív slovo o slovech, protože „spojovací objekt“ (junction object) znamená dvě věci a učím obě.

V kapitole 2 jsme našli logický spojovací objekt: spojení dvou klíčových myšlenek, které se stane samostatnou věcí s vlastními atributy. Pes umí mnoho triků, trik umí mnoho psů a Trik psa sedí mezi nimi a drží úroveň dovednosti a datum. To je logický spojovací objekt, v logickém modelu, dávno předtím, než kdokoli rozhodne o lookupu nebo master-detail.

Salesforce používá ten pojem úžeji. Když Salesforce řekne junction object, myslí tím vlastní objekt se dvěma vztahy master-detail (Create a Many-to-Many Object Relationship (otevře se v nové kartě)). Budu tomu říkat spojovací objekt Salesforce (Salesforce Junction Object). Každý spojovací objekt Salesforce je logickým spojovacím objektem, ale ne každý logický spojovací objekt se stane spojovacím objektem Salesforce: postavte ho s jedním master-detail a jedním lookupem, nebo se dvěma lookupy, a je to pořád logický spojovací objekt, jen ne ten druh od Salesforce. (Ani Salesforce sám není dokonale konzistentní: jeho vlastní referenční dokumentace objektů nazývá některé standardní objekty postavené na lookupech „junction objects“. U zkoušky předpokládejte úzkou definici.)

Ke zkoušce. Spojovací objekt Salesforce (Salesforce Junction Object) je vlastní objekt se dvěma vztahy master-detail a to Salesforce myslí, když řekne „junction object“. Logický spojovací objekt je širší modelovací myšlenka: jakýkoli objekt, který spojuje dva jiné ve vztahu mnoho k mnoha a nese vlastní atributy, ať je postavený jakkoli.

Druhým rozměrem je šířka. Může mít podřízený záznam dva nadřazené master-detail? Ano. Tři? Ne. Každý vlastní objekt může mít nejvýše dva vztahy master-detail (Considerations for Object Relationships (otevře se v nové kartě)). Dva nadřazené master-detail jsou způsob, jak postavit spojovací objekt Salesforce pro vztah mnoho k mnoha. Posádka a kamion se potkávají v přiřazení posádky a jak jsme zjistili v kapitole 2, není to instalatérství: má datum, trasu, možná stav. Spojení je místo, kde se vztah stává obchodním pojmem. Tipy Salesforce, jak ho postavit: dejte mu název, který říká, co to je, udělejte z jeho názvu záznamu automatické číslo a přejmenujte seznam souvisejících záznamů u každého hlavního záznamu podle druhého hlavního záznamu, takže stránka posádky ukazuje „Kamiony“ a stránka kamionu „Posádky“ (Create a Many-to-Many Object Relationship (otevře se v nové kartě)).

Tady je ta záludnost. Jeden ze dvou rodičů je primární a je to ten, jehož pole master-detail jste vytvořili jako první. Nic vizuálně neukazuje, který to je, takže je to klasická zkoušková otázka a klasické překvapení.

O čem primární rodič rozhoduje? O třech věcech (Create a Many-to-Many Object Relationship (otevře se v nové kartě)):

• Vzhled. Stránky spojení používají barvu a ikonu primárního hlavního záznamu.
• Vlastník. Záznamy spojení dědí vlastníka primárního hlavního záznamu. Nikdy ho neuvidíte, protože podřízený záznam nemá pole Owner; záleží na tom jen tehdy, když později odstraníte oba vztahy master-detail.
• Divize, pokud váš org používá divize, stejným způsobem.

A ten druhý je sekundární. Co to znamená?

• Je na řadě, aby se stal primárním. Smažte primární pole master-detail nebo ho převeďte na lookup a sekundární se stane primárním.
• Určuje rozsah sestav. Salesforce vám dává dva typy sestav: „Primary master with junction object and secondary master“ a „Secondary master with junction object and primary master“. Hlavní záznam uvedený jako první rozhoduje, které záznamy sestava může ukázat.
• Pro přístup se počítá stejně. Říkám to takhle: vlastnictví od primárního, přístup od obou a vyhrává to nejpřísnější. Spojení, jako každý podřízený záznam, nemá vlastní tabulku sdílení. Salesforce kontroluje přístup uživatele k oběma hlavním záznamům, přes Sharing Setting na každém poli master-detail. Pokud jsou obě nastavená na Read/Write, uživatel potřebuje Read/Write k posádce i ke kamionu, aby mohl přiřazení posádky upravit (Considerations for Object Relationships (otevře se v nové kartě)).
• Maže stejně. Smažte kterýkoli hlavní záznam, posádku nebo kamion, a jeho záznamy spojení jdou do Koše. Smažte oba a jsou nenávratně pryč.

Kliknutím zvětšíte

Pár dalších pravidel: oba hlavní záznamy mohou mít souhrnná pole ze spojení a vzorce a ověřovací pravidla spojení mohou sahat na pole obou. Spojení ale nemůže být hlavním záznamem ničeho dalšího, takže nemůže sedět uprostřed vrstvení, a oba hlavní záznamy nemohou být stejný objekt; vztah mnoho k mnoha z objektu na sebe samý potřebuje jiný návrh. A pokud má nadřazený záznam víc než 200 záznamů spojení a spojení se shrnuje do druhého nadřazeného, Salesforce vám nedovolí ten nadřazený záznam smazat, dokud jich dost neodstraníte.

Který rodič má být tedy primární? Vytvořte jako první ten, který vlastní význam. U přiřazení posádky dělá práci posádka, takže bych jako první vytvořil Crew. A pak si to zapište, protože nic na obrazovce to dalšímu člověku neřekne.

Když už jsem to všechno řekl: spojovacích objektů Salesforce nakonec moc nemívám. Objekt má typicky jednoho nadřazeného master-detail a je to stejný druh dat: zákaznická data pod zákaznickými daty, transakční pod transakčními (vzpomeňte si na druhy dat z kapitoly 2: zákaznická, transakční, referenční). Když je jeho druhý rodič jiného druhu, obvykle referenční objekt, je ten vztah lookup. Položka doručení patří ke svému doručení: master-detail, obojí transakční. Na produkt, který veze, ukazuje lookupem, protože produkt jsou referenční data s vlastním životem a nikdo nechce, aby smazání produktu vzalo s sebou roky historie doručení. Položka doručení je pořád logickým spojovacím objektem mezi doručením a produkty na něm; jen to není spojovací objekt Salesforce.

Vztahy samy na sebe: když se čára vrací

Objekt se může vázat sám na sebe: nadřazený účet, manažer, distribuční centrum, které podléhá regionálnímu hubu. Salesforce má vestavěné dva, které potkáte téměř v každém orgu: Account na Account, pole Parent Account, které staví hierarchii účtů, a Case na Case, Parent Case z modulu 2, který seskupuje související případy. Vztah sám na sebe musí být lookup a záznam nemůže ukazovat sám na sebe, i když dva záznamy mohou ukazovat jeden na druhý (Considerations for Object Relationships (otevře se v nové kartě)). Na objektu User je to zvláštní samostatný typ, hierarchický vztah, používaný pro věci jako manažer uživatele. Mechanika je snadná; na pojmenování záleží. Lookup z Distribution Center na Distribution Center pojmenovaný Distribution_Center__c nikomu nepomůže. Nadřazené? Záložní? Přetokové? Pojmenujte vztah podle role, ne podle objektu, na který ukazuje.

Kliknutím zvětšíte

Hierarchický: vlastní vztah objektu User

Tenhle je malý a je to přesně ten druh málo známého, jedinečného faktu, ze kterého bych čekal, že zkouška bude čerpat. Hierarchický vztah je zvláštní lookup, který existuje jen na objektu User. Propojuje jednoho uživatele s jiným uživatelem a Salesforce nedovolí, aby se řetězec zacyklil: uživatel nemůže ukazovat sám na sebe, přímo ani nepřímo (Object Relationships Overview (otevře se v nové kartě)). Pokud je Mariiným manažerem Dev, nemůže být Devovou manažerkou Maria ani nikdo, kdo spadá pod Marii.

To je rozdíl od vztahů samých na sebe výše. Na Account nebo na vlastním objektu mohou dva záznamy ukazovat jeden na druhý. Na User musí hierarchie zůstat hierarchií. A je to jediný způsob, jak propojit User s User: obyčejný lookup z User na sebe samý se nenabízí.

Jeden už máte. Standardní pole Manager na User je hierarchický vztah a schvalovací procesy ho mohou používat: pošli tuto žádost manažerovi předkladatele. Můžete si vytvořit i vlastní, třeba Escalation Contact nebo Backup Approver, a schvalování po něm může směrovat stejně (ApprovalProcess, Metadata API (otevře se v nové kartě)). Nepleťte si to s hierarchií rolí, která řídí přístup k záznamům. Hierarchické pole je jen vztah mezi uživateli; nesdílí ani jeden záznam.

Ke zkoušce. Hierarchický vztah existuje jen na objektu User, jako standardní pole Manager, a uživatel nemůže ukazovat sám na sebe, přímo ani nepřímo. Není to hierarchie rolí.

I vztahy mají limity

Každý objekt může mít nejvýše dva vztahy master-detail. Pole lookup a master-detail se dohromady počítají jako vztahová pole: 40 na objekt ve výchozím stavu, nejvýše 50 na požádání. Souhrnná pole: 25 na objekt ve výchozím stavu, nejvýše 40 (Increase the Maximum Relationships Allowed per Object (otevře se v nové kartě); Increase the Maximum Limit of Roll-Up Summary Fields (otevře se v nové kartě)). Salesforce dodává, že zvýšení kteréhokoli limitu může ovlivnit výkon.

K těmto číslům navrhovat nemusíte; musíte si všimnout, když se k nim blížíte. Objekt, na kterém visí vztah za vztahem, vám něco říká. Možná je opravdu tak ústřední. Nebo je možná model špatně. (A platí pravidlo rezervy z kapitoly 18: zůstaňte hluboko pod limitem, měřeno proti třetímu roku.)

Otázka 10 000 podřízených záznamů

Pak je tu nadřazený záznam s příliš mnoha podřízenými. Vlastní doporučení Salesforce je nepřekračovat zhruba 10 000 podřízených záznamů na jeden nadřazený master-detail (Considerations for Object Relationships (otevře se v nové kartě)) a jeho průvodce přístupem k záznamům ve velkém měřítku říká totéž pro vztahy nadřazený–podřízený obecně (Parent-Child Data Skew (otevře se v nové kartě)). Záznam 10 001 org nerozbije. Za tímto bodem ale uložení podřízeného záznamu může zamknout nadřazený a změny sdílení na nadřazeném se přelévají přes každý podřízený.

Když tedy vidím jeden nadřazený záznam a obrovské počty podřízených, ptám se: proč jsou všechny pod stejným nadřazeným, kdo je vlastní, jak se na ně dotazuje a jaká automatizace sahá na nadřazený záznam? Všechna doručení pod jediným účtem „Steve Trucking“ by 10 000 překročila za pár dní. Z nevinného vztahu jedna k mnoha se stává problém se skew. Další modul skew předznamenává a část 2 jde do hloubky.

Nenavrhujte čáru podle funkce

Tohle je návyk, který z tohoto modulu chci. Nezačínejte od „potřebuji souhrnné pole“, „potřebuji, aby to bylo povinné“, „chci zděděné sdílení“. To jsou implementační vodítka. Začněte od byznysu: má podřízený záznam vlastní život, kdo ho vlastní, může existovat sám, může se přesouvat, co se stane, když nadřazený zmizí, nese vztah data a jak velká může být každá strana? Pak zvolte vztah, který odpovědi implementuje.

Kliknutím zvětšíte

Nad rámec zkoušky: co mění AI. AI dokáže navrhnout vztahy za pár sekund. Neumí vám říct, jestli byznys někdy nadřazený záznam smaže. Rychlejší kreslení diagramů nedělá vrácení špatného vztahu levnějším, jakmile na něm závisí miliony záznamů a desítky automatizací.

Co tady rozhoduje architekt

• Zda má podřízený záznam vlastní životní cyklus, nebo opravdu patří k nadřazenému, a zda mají být vlastnictví a přístup vlastní, nebo zděděné.
• Zda podřízený záznam může existovat bez nadřazeného, přesouvat se mezi nadřazenými nebo přežít smazání nadřazeného.
• Co každý lookup udělá, když se jeho nadřazený záznam smaže: vymaže, zablokuje, nebo kaskádovitě smaže.
• Zda je vztah mnoho k mnoha instalatérství, nebo obchodní pojem, zda se z logického spojovacího objektu stane spojovací objekt Salesforce, který rodič je primární a co oba rodiče znamenají pro přístup.
• Zda model sedí na tvar platformy: tři vlastní podřízené úrovně do hloubky, dva nadřazení master-detail do šířky, limity vztahů a souhrnných polí.
• Zda očekávaný počet a rozložení podřízených záznamů nevytváří riziko skew, které by mělo změnit návrh.

Vztah je sada slibů o tom, jak se dva kusy dat chovají spolu. Dávejte je záměrně.

K prozkoumání

• Salesforce Help, Considerations for Object Relationships (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Object Relationships Overview (otevře se v nové kartě) a Create a Many-to-Many Object Relationship (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Roll-Up Summary Field (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Developers, Metadata API, ApprovalProcess (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Lookup Filters (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (otevře se v nové kartě) a Increase the Maximum Limit of Roll-Up Summary Fields (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (otevře se v nové kartě), ověřeno 2026-10-17.