Vlastnictví a životní cyklus

🌐 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 8 z 10 kapitoly Datová architektura Salesforce, kapitoly 3 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Vztahy mají důsledky · Další: Udržení konzistence dat

Otázka, na kterou tento modul odpovídá: Kdo záznam vlastní a co se s ním děje během celého jeho života?

Když se dívám na datový model, nechci jen vědět, jaké jsou objekty a jak se propojují. Chci vědět, co se se záznamy děje v čase. Kdo je vytváří? Kdo je vlastní? Kdo je může přeřadit? Co se stane, když se změní obchodní vztah, když už nejsou aktivní? Mají se někdy smazat a jak dlouho je uchováváme? Nic z toho se neobjeví v ERD, entitně-relačním diagramu: krabicích a čarách datového modelu z kapitoly 2. Všechno je to datová architektura. A v Salesforce je vlastnictví místem, kde do sebe narážejí datový model a model zabezpečení.

Vlastnictví je víc než jméno v poli

Administrátoři vidí na záznamu Owner a čtou ho jako popisek: Bart vlastní tento účet, Lisa vlastní tamten případ. Může to znamenat i tohle. V Salesforce je ale vlastnictví také mechanismem platformy. U objektů, které mají vlastníka, řídí vlastník to, kdo záznam vidí, přes hierarchii rolí, pravidla sdílení, fronty a přeřazování. Když se tedy ptám „kdo vlastní tento záznam?“, neptám se, čí jméno je na stránce. Ptám se, jaké chování zabezpečení a životního cyklu k němu připojujeme. Vlastníkem může být uživatel, nebo u některých objektů, mimo jiné u vlastních objektů, případů a zájemců, fronta, a v obou případech dostane vlastník k záznamu plný přístup (Understanding Sharing (otevře se v nové kartě)).

Proto odděluji obchodní odpovědnost od vlastnictví záznamu. Někdy jde o stejného člověka. Někdy ne. Pokud byznys říká, že za doručení odpovídá dispečer, nedělá to z dispečera automaticky vlastníka. Odpovědnost může žít ve vlastním poli, zatímco vlastnictví je nastavené tak, aby podporovalo zabezpečení a měřítko. Nenechte ty dvě věci splývat jen proto, že obě používají slovo „vlastník“.

Tabulka sdílení: kde se z vlastnictví stává přístup

Někteří lidé ani nevědí, co je tabulka sdílení. Každý datový architekt by to vědět měl.

Většina sdílení záznamu se drží v souvisejícím objektu sdílení (share object), verzi seznamu řízení přístupu (ACL) od Salesforce (Understanding Sharing (otevře se v nové kartě)). Account má AccountShare, Contact má ContactShare a vlastní objekt dostane svůj vlastní: Truck__c má Truck__Share (Sharing a Record Using Apex (otevře se v nové kartě)). Každý řádek v něm říká čtyři věci:

• Který záznam: ID nadřazeného záznamu.
• Komu: uživateli, nebo skupině (veřejné skupině, skupině role, teritoriu).
• Kolik: Read, Edit, nebo All (plný přístup).
• Proč: důvod řádku (row cause). Owner pro vlastníka, Rule pro pravidlo sdílení, Manual pro ruční sdílení, Team, implicitní důvody, které Salesforce přidává mezi účtem a jeho podřízenými záznamy, a důvody, které vývojář definuje pro sdílení v Apexu.

Ve třídě otevřu Workbench a dotazuji se na tabulku sdílení, zatímco záznam sdílím, a vy sledujete, jak se řádky objevují a mizí. Když se někdo zeptá „proč tenhle člověk vidí tamto?“, odpověď často sedí v jednom řádku, i s důvodem.

Není v ní ale všechno. Výchozí nastavení celé organizace (OWD) není řádek. Hierarchie rolí tam také není uložená: přístup pro lidi nad vlastníkem se počítá, když je potřeba. A View All, Modify All, View All Data a Modify All Data tabulku sdílení úplně přeskakují (Sharing a Record Using Apex (otevře se v nové kartě)). Jak říkám ve třídě: zaškrtněte View All a obešli jste tabulku sdílení.

Salesforce také některé záznamy sdílí za vás, kvůli tomu, jak spolu souvisejí. To je implicitní sdílení a funguje mezi účtem a jeho podřízenými záznamy. Pokud vidíte kontakt, případ nebo příležitost, můžete také číst účet, ke kterému patří. A vlastník účtu dostane přístup ke kontaktům, případům a příležitostem účtu, na úrovni nastavené rolí vlastníka (Implicit Sharing (otevře se v nové kartě)). V posledních vydáních Salesforce část toho přístupu k podřízeným záznamům počítá, když je potřeba, místo aby ho ukládal jako řádky, takže se nedivte, když ho dotaz na tabulku sdílení neukáže. Tady vám dávám jen nápovědu; podrobnosti jsou v kapitole Vztahy a vestavěné sdílení.

Ještě jedna výjimka, pro případ, že máte hodně externích uživatelů. Komunitní uživatelé s vysokým objemem, licence Customer Community postavené pro tisíce až miliony zákazníků, nemají žádnou roli, nemohou být ve veřejných skupinách a nelze jim dát záznamy přes pravidla sdílení ani ruční sdílení (About High-Volume Community or Site Users (otevře se v nové kartě); Sharing Rule Considerations (otevře se v nové kartě)). Pro ně tabulka sdílení odpovědí není: k záznamům se dostávají přes sady sdílení, které párují účet nebo kontakt záznamu s vlastním účtem nebo kontaktem uživatele. Je to jeden z důvodů, proč tyto licence škálují. Kurz Sharing and Visibility to pokrývá v kapitole Sdílení s externími uživateli.

A vzpomeňte si na modul 7: podřízený objekt nemá vůbec žádný objekt sdílení. Jeho přístup pochází z objektu sdílení hlavního záznamu a ze Sharing Setting na poli master-detail.

Proč to datového architekta zajímá? Protože vlastnictví se zapisuje do této tabulky. Každá změna vlastníka, každé nové pravidlo sdílení, každý uživatel, který se přesune mezi rolemi nebo skupinami, znamená, že Salesforce přidává a odebírá řádky. U pár tisíc záznamů si toho nikdo nevšimne. U deseti milionů, kdy většinu z nich vlastní jeden uživatel, je to ten přepočet, se kterým se za chvíli setkáme.

Ke zkoušce. Objekt sdílení vlastního objektu se jmenuje Object__Share, třeba Truck__Share. Podřízený objekt nemá objekt sdílení: jeho přístup pochází z hlavního záznamu. A když se vlastník záznamu změní, jeho ruční sdílení se odstraní, zatímco sdílení v Apexu s vlastním důvodem vývojáře zůstane.

Tady datový model předává štafetu modelu zabezpečení a zbytek učím v kurzu Sharing and Visibility Architect: Steveových 22 způsobů, jak sdílet záznam, Výchozí nastavení celé organizace, vlastnictví, fronty a hierarchie rolí, Vztahy a vestavěné sdílení pro implicitní sdílení a Programové sdílení a bezpečný kód pro důvody sdílení v Apexu. V tomto kurzu to pro lidi, aplikace a agenty dává dohromady kapitola 12.

Někdy se vlastnictví dědí

V minulém modulu jsme viděli, že podřízený záznam master-detail nemá vlastního vlastníka; řídí se svým nadřazeným. To je často přesně správně. Potřebuje byznys jiného vlastníka pro každou položku na doručení? Ne. Doručení vlastní životní cyklus a položka k němu patří. Proto se návrh vztahů a návrh vlastnictví dějí společně: když jste zvolili master-detail, udělali jste už část rozhodnutí o vlastnictví.

Kdo vlastní záznamy, které vytvářejí systémy?

Teď to začne být zajímavé. Člověk vytvoří účet a možná se stane vlastníkem. ERP ale přes noc pošle 100 000 transakcí. Kdo je vlastní? Integrační uživatel? Fronta? Regionální vlastník odvozený z dat? Systémový účet, na který pět let nikdo nepomyslel? A teď záznamy vytvářejí i agenti.

Můj postoj: záleží na tom, jestli je vlastnictví důležité pro sdílení. Integrační uživatel, nebo uživatel agenta, je platný uživatel a může záznamy vlastnit. Pokud vlastnictví v daném objektu řídí přístup (přes hierarchii rolí nebo pravidla sdílení), přiřaďte záznamy správnému vlastníkovi: skutečnému uživateli, frontě, nebo vyhrazenému uživateli vlastníkovi. Pokud ne, může být lepší volbou ponechat jako vlastníka systémového uživatele, protože pak auditní stopa vede přímo zpátky k tomu, co záznam vytvořilo.

Tak či onak to rozhodněte záměrně. Integrační účet, který vlastní všechno, se potichu stal součástí vaší architektury zabezpečení a někdo musí vědět, co se stane, když se někdy deaktivuje.

Vlastnictví se může stát problémem měřítka

Záleží i na rozložení. Deset milionů záznamů rozprostřených mezi tisíce vlastníků je jeden tvar. Deset milionů záznamů vlastněných jedním uživatelem je úplně jiný. Salesforce tomu říká ownership data skew (nerovnoměrné rozložení vlastnictví), když jeden uživatel vlastní víc než 10 000 záznamů objektu (Ownership Data Skew (otevře se v nové kartě)). Obvykle se to stane, když někdo všechno zaparkuje na jednoho uživatele nebo frontu: všechny nepřiřazené zájemce na zástupného uživatele, každý integrační záznam na integračního uživatele. Je to neškodné, dokud se ten uživatel nepřesune v hierarchii rolí nebo do skupiny či ze skupiny, na které závisí pravidlo sdílení. Pak musí Salesforce upravit obrovské množství záznamů sdílení a dostanete dlouhé přepočty.

Doporučení jsou praktická. Kde to jde, rozprostřete vlastnictví mezi víc uživatelů. Pokud jeden uživatel musí vlastnit hodně, držte ho mimo hierarchii rolí; pokud roli potřebuje, dejte ho do vlastní role úplně nahoře a nepřesouvejte ho, a držte ho mimo veřejné skupiny, které používají pravidla sdílení (Ownership Data Skew (otevře se v nové kartě)). Stejná úvaha platí pro nadřazený záznam s příliš mnoha podřízenými z minulého modulu, parent-child skew.

Rozložení je tedy součástí fyzického modelu. Neptejte se jen, kolik záznamů; ptejte se, jak jsou rozložené. Je to další verze „počtu nul“: nejen kolik nul, ale kde jsou nuly soustředěné. Část 2 jde do skew hluboko; tady chci, abyste ho viděli přicházet. Kurz Sharing and Visibility se k tomu vrací v kapitole Sdílení ve velkém měřítku.

Z „výchozího vlastníka“ se stává architektura

Tady je vzor, který vídám pořád. Nikdo neví, kdo by měl něco vlastnit, a tak někdo řekne: „Prostě je všechny přiřaďte integračnímu uživateli,“ nebo „vytvořte obecného uživatele jménem System.“ Možná je to správně. Nedělejte to ale náhodou. Dočasné výchozí řešení má ve zvyku stát se trvalým: o dva roky později patří každý záznam integration@company.com, nikdo si nepamatuje proč a změna je projekt. To je test vratnosti z kapitoly 1: než dáte milion záznamů jednomu vlastníkovi, zeptejte se, co bude stát to později změnit.

Přeřazení je událost životního cyklu

Vlastníci se mění. Obchodníci odcházejí, teritoria se přesouvají, týmy se reorganizují, regiony se vyvažují. Co závisí na vlastníkovi: sdílení, automatizace, sestavy, fronty, eskalace, integrace? Pokud změna vlastníka mění, kdo záznam vidí, přeřazení není úklid administrátora. Je to bezpečnostní událost, a u milionu záznamů i provozní. Sledujte tabulku sdílení, když se to stane: ruční sdílení se při změně vlastníka odstraní, zatímco sdílení v Apexu s vlastním důvodem vývojáře změnu přežije (Understanding Sharing (otevře se v nové kartě)). Ve třídě s někým nasdílím záznam, změním vlastníka a ten člověk ztratí přístup. Místnost je vždycky překvapená.

A pamatujte, že vlastnictví není totéž co přístup. Vlastník není jediný, kdo potřebuje záznam vidět, a Salesforce má mnoho způsobů, jak přístup udělit: hierarchii rolí, pravidla sdílení, týmy, teritoria, ruční a programové sdílení. Kurz Sharing and Visibility do nich jde hluboko, počínaje kapitolou Steveových 22 způsobů, jak sdílet záznam. Architektova pointa je jednodušší: neřešte vlastnictvím každý problém s přístupem. Pokud přesouváte vlastníky jen proto, aby někdo viděl záznam, nejspíš řešíte špatný problém.

Vytvoření je jen začátek

Spousta datového modelování končí u vytvoření: pole, objekt, vztah, hotovo. Záznam ale může žít deset let. Aktualizuje se, mění vlastníky, mění stav i vztahy, stane se neaktivním, stane se historií, možná bude potřebovat archivaci a jednoho dne možná smazání. Architektura není jen o tom, jak se záznam narodí. Je o tom, co se děje od narození do smrti.

Kliknutím zvětšíte

Nemažte jen proto, že je něco staré

Maloobchodní partner přestane posílat práci. Smazat účet? Ne automaticky: jeho doručení, reklamace a historie fakturace jsou pořád důležité. Kamion je vyřazen z provozu. Smazat ho, i s historií jeho doručení a reklamacemi škod? Věc už možná není aktivní, ale její data ano. Odděluji proto neaktivní od pryč. Vyřazený kamion může v modelu zůstat; bývalý zaměstnanec se může pořád objevovat v auditní historii. Architektura musí uchovat fakta, na kterých záleží i po skončení provozního vztahu.

Uchovávání je obchodní požadavek

Druhá strana: uchovávat všechno navždy také není architektura. Úložiště roste, sestavy se zpomalují, vyhledávání je zašuměnější a zákon o ochraně soukromí může říkat, že některá data musí pryč. Chci proto výslovnou odpověď na otázku jak dlouho tohle uchováváme? „Salesforce to uchovává“ není politika uchovávání.

A většinou je to otázka transakčních dat. Referenční data, produkty, typy služeb, distribuční centra, se nezvětšují do obřích rozměrů a ukazují na ně jiné záznamy, takže obvykle zůstávají. Zákaznická data jsou někde mezi: může přijít den, kdy zákazníkovi ukončíte životní cyklus, zvlášť když držíte osobní údaje a důvod je držet pomine. Objem je ale v transakcích: doručeních, objednávkách, případech, schůzkách, vytvářených každý den, navždy. To je to, co roste do stovek milionů řádků, a tam musí být uchovávání výslovné: možná dva roky provozních dat v orgu, sedm let finančních záznamů někde jinde, devadesát dní pro některé fotky. To jsou obchodní pravidla, a pokud se nikdo nezeptal, měl by se zeptat architekt.

Ve třídě to říkám roky: pokud dnes nearchivujete, budete vůbec někdy archivovat? „Vyřešíme to později“ má ve zvyku stát se nouzovým projektem u tří set milionů záznamů. Část 2 má celý modul o archivaci a čištění, postavený na stejné otázce.

Steve Trucking: kdo vlastní doručení?

Doručení se vytváří z manifestu maloobchodního partnera, integrací, asi 3 300krát denně. Kdo ho vlastní? Ne maloobchodní partner; to je obchodní vztah. Ne příjemce. Posádka ho provádí, ale měl by záznam měnit vlastníka pokaždé, když si posádky vymění kamiony? Dispečer? Distribuční centrum? Fronta? Integrační uživatel, který ho vytvořil?

Teď použijte tento modul, počínaje otázkou, která to rozhodne: řídí vlastnictví něčí přístup k doručením? Ve Steve Trucking ne. Dispečeři vidí doručení svého distribučního centra, posádky ta na svých trasách a každý obchodník vidí ta svá na partnerském portálu. Nic z toho nezávisí na tom, kdo záznam vlastní; pochází to z distribučního centra, trasy a partnera.

Moje odpověď tedy: doručení vlastní integrační uživatel. Je to dobrý příklad systémového uživatele, který záznamy vlastní záměrně:

• Auditní stopa je poctivá. Vlastník každého doručení říká, odkud přišlo: z integrace manifestů.
• Přístup pochází ze sdílení, ne z vlastnictví. Pravidla sdílení podle kritérií na distribučním centru dávají týmu každého DC jeho doručení; partneři se ke svým dostávají přes portál.
• Skew je vynavržený pryč. Při 3 300 denně překročí integrační uživatel 10 000 doručení za tři dny, takže je to ownership skew od prvního dne, a to je v pořádku, pokud s ním počítáme. Integrační uživatel nemá žádnou roli, takže nad ním v hierarchii není nic, co by se muselo přepočítávat, a zůstává mimo veřejné skupiny, které používají naše pravidla sdílení.
• Nikdo doručení nepřeřazuje. Posádky si mění kamiony a dispečeři střídají směny a vlastník se nikdy nepohne, takže nenastane žádná bouře přeřazování a žádná ruční sdílení, o která by se dalo přijít.

A zapište si, co se stane, když se ten uživatel někdy deaktivuje nebo nahradí, protože teď vlastní miliony záznamů. To je rozhodnutí, které bude další tým potřebovat najít.

Nad rámec zkoušky: co mění AI. Agenti vytvářejí a mění záznamy strojovou rychlostí. Pokud agent vytvoří 100 000 záznamů pod svým vlastním uživatelem, z „vlastníka spravíme později“ se stane skew, přepočet sdílení a úklidový projekt. Rozhodněte pravidlo vlastnictví pro agenta dřív, než se spustí, stejnou otázkou: je tu vlastnictví důležité pro sdílení?

Co tady rozhoduje architekt

• Zda vlastnictví představuje obchodní odpovědnost, bezpečnostní mechanismus, nebo obojí, a kde žije odpovědnost, pokud ne v poli Owner.
• Zda záznamy potřebují vlastního vlastníka, nebo ho mají zdědit od nadřazeného.
• Kdo vlastní záznamy, které vytvářejí integrace a agenti, podle toho, jestli vlastnictví řídí sdílení.
• Jak je vlastnictví rozložené a jak se vyhnout ownership skew, když jeden uživatel musí vlastnit hodně.
• Kdy se záznamy stanou neaktivními, kdy se archivují, jak dlouho se uchovávají a kdy je správné je smazat.

Když se díváte na fyzický model, neptejte se jen, kde jsou data uložená. Ptejte se, kdo je vlastní dnes, kdo je může vlastnit zítra a co se stane, když už je nebudeme potřebovat. Příště: i se správným objektem, poli, vztahy a vlastníkem musí data zůstat důvěryhodná.

K prozkoumání

• Apex Developer Guide, Understanding Sharing (otevře se v nové kartě), ověřeno 2026-10-17: vlastníci (uživatel, nebo fronta u vlastních objektů, případů a zájemců) mají plný přístup; většina sdílení žije v souvisejícím objektu sdílení; hierarchie rolí se odvozuje za běhu; ruční sdílení se při změně vlastníka odstraní, spravované sdílení v Apexu se ponechá; hodnoty důvodu řádku.
• Apex Developer Guide, Sharing a Record Using Apex (otevře se v nové kartě), ověřeno 2026-10-17: AccountShare, MyCustomObject__Share; podřízené objekty nemají objekt sdílení; co objekt sdílení nesleduje (OWD, hierarchie rolí, View All a Modify All).
• Salesforce Help, Implicit Sharing (otevře se v nové kartě), ověřeno 2026-10-17: přístup mezi účtem a jeho kontakty, případy a příležitostmi.
• Salesforce Help, About High-Volume Community or Site Users (otevře se v nové kartě) a Sharing Rule Considerations (otevře se v nové kartě), ověřeno 2026-10-17: žádné role, žádná pravidla sdílení ani ruční sdílení; místo toho sady sdílení.
• Kurz Sharing and Visibility Architect: Steveových 22 způsobů, jak sdílet záznam, Výchozí nastavení celé organizace, vlastnictví, fronty a hierarchie rolí, Vztahy a vestavěné sdílení, Programové sdílení a bezpečný kód, Sdílení s externími uživateli, Sdílení ve velkém měřítku.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (otevře se v nové kartě) a Parent-Child Data Skew (otevře se v nové kartě), ověřeno 2026-10-17.