Udržení konzistence dat

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

Otázka, na kterou tento modul odpovídá: Jak udržet data konzistentní a co stojí každá vrstva?

Čistá data chce každý. Nikdy jsem nepřišel na schůzku k požadavkům, kde by někdo řekl: „Nejradši bychom měli nekonzistentní data.“ Neshoda přichází později: kde pravidla vynucovat? Na obrazovce? Povinným polem? Výběrovým seznamem, ověřovacím pravidlem, pravidlem duplicit, flow, Apexem? Všechno to pomáhá. Není to zaměnitelné a každá vrstva něco stojí.

Moje obecné pravidlo zní posuňte pravidlo tak nízko, jak to rozumně jde. Pokud může být hodnota jen jednou z pěti věcí, nenechte lidi psát cokoli a pak to uklízet automatizací. Pokud dva záznamy nikdy nesmějí sdílet identifikátor, nespoléhejte na to, že si toho někdo všimne v sestavě. Pokud má pravidlo platit, ať záznam přijde z obrazovky, z API, z integrace, z nahrávání dat nebo od agenta, nevynucujte ho jen v rozhraní. Čím blíž pravidlo sedí k datům, tím těžší je ho obejít. Říkám tomu žebříček konzistence.

Příčka první: typ pole a slovník

První pravidlo konzistence je to z modulu 6: zvolte správný typ. Datum je Date, okamžik je Date/Time, peníze jsou Currency. To je konzistence dřív, než kdokoli napíše pravidlo.

Udělejte ze stavu doručení textové pole a dostanete Delivered, delivered, DELIVERED, Complete, Done a Dropped off a někdo bude muset zjistit, jestli těch šest znamená totéž. Nebo definujte slovník jednou: Delivered, jedna hodnota, jeden význam. Udělejte z něj omezený výběrový seznam, aby odmítl cokoli, co není na seznamu, i přes API, a globální sadu hodnot, když seznam sdílí několik polí (podrobnosti má modul 6).

Nepoužívejte ale výběrový seznam jen proto, abyste lidem zabránili psát. Je to opravdu hodnota, nebo další entita? Devět distribučních center, každé s názvem, může vypadat jako výběrový seznam; devět s adresami, vedoucími, kapacitou a kamiony jsou záznamy. Pravidlo má model posilovat, ne vyvažovat špatný model. A pokud jde opravdu o řízený slovník, řiďte ho na poli. Nedovolte chaos, abyste pak stavěli flow, které z AZ, Arizona, Ariz a Phoenix area udělá hodnotu, kterou jste chtěli hned na začátku.

Příčka druhá: Required a Unique

Required a Unique lákají, protože jsou jednoduché: zaškrtněte políčko a problém je vyřešený. Někdy. Pokud má každý kamion číslo ve flotile od chvíle, kdy je vytvořen, a žádné dva kamiony nemají stejné, vyjadřují obě políčka skutečná obchodní pravidla. To je silná konzistence.

Jakmile ale platforma pravidlo vynucuje, nezajímá ji, že váš proces má v úterý odpoledne výjimku. Tenhle příklad používám ve třídě roky. Objekt existuje nějakou dobu, se spoustou záznamů. Někdo přidá pole a zaškrtne Required. Otestuje vytvoření záznamu: funguje nádherně. Pak sobotní noc, nasazení, běží testy a stará testovací třída vytváří objekt bez nového pole. Bum. Nebo někdo upraví starý záznam z doby, kdy pole neexistovalo. Nebo integrace pošle stejný payload, jaký posílá pět let. Bum. „Ale to pole jsme neměnili.“ Platformu to nezajímá: změnili jste kontrakt toho, co je platný záznam. Nové pravidlo neovlivní jen nová data; mění, co můžete dělat se starými.

Příčka třetí: ověřovací pravidla

Ověřovací pravidla nám umožňují říkat mnohem bohatší věci. Pokud je stav Delivered, musí být vyplněný skutečný čas doručení. Pokud je zastávka instalace, musí být kontrolní seznam dokončený, než se zastávka dá uzavřít. Spouštějí se při uložení záznamu, takže záznam chrání, ať byl uložený ze stránky, z API, z nahrávání dat, z integrace nebo od agenta. O to jde. Pokud má pravidlo záznam chránit, dejte ho tam, kde ho potká každý zápis.

Mají také zuby. To je jejich síla i jejich cena.

Problém starých záznamů

Tady to začne být ošklivé. Máte milion záznamů a dnes přidáte pravidlo: čas doručení nesmí být před odjezdem trasy. Rozumné. Dvacet tisíc starých záznamů ho ale porušuje, díky migraci před sedmi lety. Uživatel jeden z nich otevře a změní telefonní číslo. Uložit. Pravidlo se spustí. „Změnil jsem telefonní číslo. Proč mi říkáte něco o čase doručení z roku 2019?“ Oprávněná otázka.

Ověřovací pravidlo by tedy nemělo říkat jen, co musí platit. Mělo by říkat, kdy to vynucovat. Funkce jako ISNEW() a ISCHANGED() umožňují omezit pravidlo na nové záznamy nebo na uložení, při kterých se příslušná pole skutečně mění (Validation Rule Considerations (otevře se v nové kartě)).

Záznam se ale nemění jen tehdy, když ho upraví člověk, a mnoho důvodů nemáte pod kontrolou. Integrace přes noc aktualizuje stav. Flow vyplní datum. Manažer přeřadí teritorium a vlastník se změní na deseti tisících záznamech. Někdo upraví položku doručení, souhrnné pole na doručení se přepočítá a tím se doručení uloží, takže se ověřovací pravidlo doručení spustí pro uživatele, který na něj vůbec nesáhl (Roll-Up Summary Field (otevře se v nové kartě) varuje, že chyby ověření se mohou zobrazit na podřízeném nebo hlavním záznamu). Každé z těch uložení potká vaše nové pravidlo. U každého nového pravidla se tedy ptejte: má toto pravidlo platit pro to uložení?

Tohle jsou možnosti a vplétáte je do pravidla:

• Vždycky, při každém uložení. Správně, když je pravidlo opravdu o záznamu a stará data projdou. Vězte ale, co znamená „každé uložení“: dávková úloha, která mění jen vlastníka, nebo jakákoli drobná úprava kteréhokoli pole na záznamu, ho musí projít také.
• Jen pro nové záznamy, s ISNEW(). Pravidlo zkontroluje záznam jednou, při vytvoření, a už nikdy. Minulost zůstane, jaká byla, ale stejně tak budoucnost: pozdější úprava může způsobit, že nový záznam pravidlo poruší, a nikdo to nezastaví. Pokud na tom záleží, spojte ho s další možností.
• Jen když se mění pole, kterých se týká, s ISCHANGED(). Úprava telefonního čísla pravidlo o čase doručení nevzbudí.
• Ne pro určité zapisovatele. Vlastní oprávnění (custom permission), kontrolované ve vzorci jako $Permission, nechá projít integračního uživatele nebo migraci dat, zatímco lidé pravidlo dál potkávají (How to Reference a Custom Permission in a Validation Rule (otevře se v nové kartě)). Dávejte ho záměrně a málokomu.
• Od určitého data dál, porovnáním CreatedDate se dnem, kdy pravidlo začalo platit, když „nový“ znamená „od té doby, co to vynucujeme“. Na rozdíl od ISNEW() kontroluje tyto záznamy při každém pozdějším uložení, takže platí stejné varování: drobná změna, jako dávková změna vlastníka, může selhat na záznamu, který se mezitím odchýlil.

Přidáváte pravidlo k záznamům, které už máte? Než ho zapnete, promyslete důsledky. Každý existující záznam ho teď musí projít při svém příštím uložení a to uložení může přijít odněkud, kde byste ho nečekali: z noční integrace, z dávkové změny vlastníka, ze souhrnného pole, z hromadné aktualizace ze zobrazení seznamu. Které z nich na něj narazí a co se stane s tou úlohou, když jeden záznam selže? Část Než to zapnete obsahuje postup, který používám.

Nepřepisujte historii, aby bylo pravidlo spokojené

Co s těmi dvaceti tisíci starými záznamy? Pokud jsou data špatně a znáte správné hodnoty, opravte je. Viděl jsem ale i jiný druh „opravy“: historickou pravdu nikdo nezná, jen potřebují, aby záznamy prošly, a tak je aktualizují hodnotami, které vyhoví dnešnímu pravidlu. To nemám rád. Aktualizace starých záznamů kvůli souladu změní LastModifiedDate a zničí klíčové historické informace a vymýšlení hodnot znamená předstírat, že o minulosti víme něco, co nevíme. Dejte pravidlu výjimku pro záznamy, které jsou starší než ono, místo přepisování historie. Může to být ošklivé, ale je to poctivé.

Ověření v rozhraní není ověření dat

Udělejte pole povinným v rozvržení stránky a uživatelé bez něj neuloží. Pak noční integrace vloží 50 000 záznamů. Použila vaši stránku? Ne. Ani hromadné nahrávání, klient API nebo agent. Požadavek v rozhraní chrání tu obrazovku, ne data. Stejně se dá obejít i ověření polí v Dynamic Forms. Ptejte se tedy: kudy mohou tato data vstoupit? Lightning, portál, mobil, integrace, API, hromadné nahrávání, Flow, Apex, agent. Čím víc dveří je, tím méně věřím pravidlu, které hlídá jen jedny z nich.

Příčka čtvrtá: pravidla duplicit

Teď se posouváme od konzistence uvnitř záznamu ke konzistenci napříč záznamy. Acme Corporation, ACME Corp, Acme Inc.: čtyři zákazníci, nebo jeden? Na to žádné pravidlo pole neodpoví. Pravidla shody (matching rules) definují, jak se záznamy porovnávají; pravidla duplicit (duplicate rules) rozhodují, co se stane, když se najde pravděpodobná duplicita: povolit s varováním, zablokovat, nebo nahlásit. Můžete mít až pět aktivních pravidel duplicit na objekt a v každém až tři pravidla shody a klíče shody zužují každé porovnání na 100 nejpravděpodobnějších duplicit (Things to Know About Duplicate Rules (otevře se v nové kartě)).

Jejich cenou je tření. Pokud každý účet, který obchodník vytvoří, hlásí Possible duplicate found, je to někdy přesně to, co chcete, a někdy se lidé naučí proklikat se dál, aniž by četli. Legitimní záznamy si mohou být podobné a integrace může potřebovat jiné chování než člověk. A varování je vlastní varování Salesforce: jeho upozornění a seznam možných duplicit nemusí zapadnout do vlastní obrazovky, kterou jste postavili, a když je uložení bez rozhraní (headless), integrace, nahrávání dat, agent, není žádná obrazovka, kde by se dalo ukázat. Rozhodněte tedy, jak se duplicita projeví na každé cestě: varování pro člověka, zablokované uložení a chyba pro API, nebo volba Report a sady duplicitních záznamů, které někdo později prověří. Dobrá architektura není maximální vynucení; je to správné vynucení.

A zkontrolujte, které dveře pravidlo duplicit skutečně hlídá (Things to Know About Duplicate Rules (otevře se v nové kartě)). Přes API a nástroje pro import nikdo varování nevidí: pravidlo nastavené na upozornění uložení prostě zablokuje. Některé cesty pravidla úplně přeskakují: Quick Create, tlačítko Undelete, ruční sloučení, záznamy přidané přes Lightning Sync nebo Einstein Activity Capture. A záznamy uložené ve stejnou chvíli se neporovnávají mezi sebou, jen se záznamy, které už v Salesforce jsou. Nahrajte soubor, ve kterém je stejný zákazník dvakrát, a oba řádky mohou projít. Pravidlo duplicit je dobrá síť. Není to zámek na dveřích.

Ke zkoušce. Pravidla duplicit neporovnávají mezi sebou záznamy uložené ve stejnou chvíli, jen se záznamy, které už v Salesforce jsou. Přes API a nástroje pro import se upozornění nezobrazí: duplicita, kterou pravidlo zachytí, se prostě neuloží. A uložení a všechno, co spustí, běží jako jedna transakce: pokud kterákoli část selže, všechno se vrátí zpět.

Jedna hranice. Pravidla duplicit udržují čistý jeden org. Neřeší podnikovou identitu. Pokud má Salesforce Acme Corporation, ERP má ACME-10382 a fakturace zákazníka 77193, pravidlo duplicit vám neřekne, že jde o stejnou firmu. To jsou kmenová data, kapitola 6.

Příčka pátá: automatizace

Některá pravidla jsou na nižší příčky příliš složitá: potřebují související záznamy, jiný systém, závislé záznamy, vícekrokový proces. To je Flow, Apex, někdy integrační logika. (Ne Workflow Rules ani Process Builder; ty už nejsou podporované.) Automatizace je silná a dražší: víc pohyblivých částí, víc testování, víc ošetření chyb, víc způsobů, jak jedna automatizace zakopne o druhou. A kód přináší vlastní chyby. Pokud to dokáže vynutit typ pole, Apex nepíšu. Pokud to ověřovací pravidlo řekne jasně, nestavím flow jen proto, že Flow existuje. Neřešte problém pole procesním motorem.

Všechno, nebo nic: když se záznamy mění společně

Zatím každá příčka chrání jedno uložení. Záznamy se ale mění společně: doručení a jeho položky, objednávka a její řádky, flow, které aktualizuje tři objekty. Tady vám platforma dává silnou záruku. Uložení a všechno, co spustí, triggery, flow, třídy, které volají, běží jako jedna transakce: pokud kterákoli část selže, celé se to vrátí zpět a nic se nepotvrdí (Apex Transactions (otevře se v nové kartě)). Nedostanete půl doručení.

Hromadná práce je výjimka, kterou si volíte. Nahrávání dat nebo metoda Database v Apexu může povolit částečný úspěch: dobré záznamy se uloží, špatné se vrátí s chybami a někdo se s nimi musí vypořádat (DML Statements vs. Database Class Methods (otevře se v nové kartě)). U nahrávání milionu řádků je to často správně, ale pak je konzistence procesem: kdo čte soubor s chybami a co se stane se záznamy, které selhaly?

A pak je tu načasování. Dvě uložení ve stejnou chvíli mohou obě projít kontrolou, kterou by každé samo neprošlo. Flow, které hledá existující objednávku a pak jednu vytvoří, může pustit dvě, a právě jsme viděli, že pravidla duplicit neporovnávají záznamy uložené ve stejnou chvíli. Pole označené Unique, nebo External ID, kontroluje platforma při každém uložení, takže vyhraje jen jedno z nich. To je další důvod posunout jedinečnost dolů na pole. Zámky, soupeření o zdroje a opakování jsou samostatné téma; kapitola 11, Transakce, souběžnost a spolehlivost, jde do hloubky.

Posuňte pravidlo dolů, dokud tam nepřestane patřit

„Tak nízko, jak to rozumně jde“ neznamená „vždycky na nejnižší“. Pokud je pole povinné, až když příležitost dosáhne určité fáze, je jeho povinnost ve schématu špatně; pravidlo je podmíněné, takže správnou příčkou je ověřovací pravidlo. Pokud má duplicita varovat člověka, ale schválená integrace má vlastní odsouhlasení, navrhněte pro obě cesty. Cíl: nejnižší vrstva, která obchodní pravidlo správně reprezentuje.

Každá vrstva něco stojí

Kliknutím zvětšíte

Tohle je kompromis, který chci, abyste viděli. Typy polí a řízené hodnoty jsou jednoduché a silné, ale jen pro to, co dokáže pole vyjádřit. Required a Unique jsou tupé: jakmile jsou zapnuté, musí jim vyhovět každý zápis. Ověřovací pravidla vyjadřují bohatší podmínky, ale mohou zablokovat úpravy starých záznamů a překvapit nasazení. Pravidla duplicit chrání napříč záznamy, ale přidávají tření uživatelům i integracím. Automatizace zvládne cokoli, ale nutí vás vlastnit orchestraci, chyby, testy i výkon. Žádná vrstva není zadarmo. Volte vrstvu každého pravidla s vědomím, jak selhává.

Než to zapnete

Přidání pravidla do existujícího orgu je zavádění, ne zaškrtávací políčko. Kolik záznamů ho dnes porušuje a proč? Jsou skutečně špatně? Můžeme znát správnou hodnotu? Platí pravidlo i historicky, nebo jen odteď? Které integrace, testy a automatizace na něj narazí? Dobrý postup: změřit, vyčistit, o čem dokážete prokázat, že je to špatně, omezit rozsah pravidla, přidat záměrnou výjimku pro legitimní historii, otestovat každou cestu zápisu a pak vynutit. Měření a čištění jsou samostatné disciplíny, profilování, standardizace, monitorování, péče o data, a pokrývá je kapitola 5, Kvalita dat a správa dat. Mnohem lepší než zaškrtnout políčko v pátek a v sobotu v noci zjišťovat důsledky.

Nad rámec zkoušky: co mění AI. Agent dokáže vytvářet záznamy rychleji než jakýkoli člověk, a špatné záznamy stejně rychle. „Uživatelé vědí, že tohle se nedělá“ není ochrana, když je uživatelem agent. Dejte důležitá pravidla do datové vrstvy, kde je potká každý zapisovatel, aby si agent nemusel pamatovat nepsaná pravidla firmy.

Steve Trucking: chraňte doručení

Vezměte doručení. Jeho stav pochází z jednoho slovníku: výběrový seznam, omezený. Reference objednávky maloobchodního partnera musí být jedinečná pro každého partnera, takže je to External ID, označené jako jedinečné, používané k upsertu manifestu. Skutečný čas doručení je povinný, jakmile je stav Delivered: ověřovací pravidlo, omezené na tuto změnu. Zastávku s instalací nelze uzavřít, dokud není dokončený její kontrolní seznam a pořízené povinné fotky (u myčky nádobí přívod vody, odpad a vyrovnání): ověřovací pravidlo, nebo automatizace, pokud musí kontrolovat fotky uložené mimo platformu. Stejnou objednávku, která přijde dvakrát z opakovaně odeslaného manifestu, zachytí External ID; dvě různé objednávky, které vypadají podobně, jsou otázkou párování.

Všimněte si, že jsem neřekl „dejte je všechny do flow“. Každé pravidlo sedí na vlastní příčce. U každého pravidla se ptejte: jaká je nejnižší vrstva, která ho správně vynutí pro každou cestu zápisu, na které záleží?

Co tady rozhoduje architekt

• Na kterou příčku patří každé pravidlo: typ pole, řízený slovník, povinnost nebo jedinečnost, ověřovací pravidlo, pravidlo duplicit, nebo automatizace.
• Které cesty zápisu musí být chráněné: rozhraní, portál, mobil, integrace, hromadná nahrávání, API, automatizace a agenti.
• Zda nové pravidlo platí pro historické záznamy, nebo je omezené na nová a změněná data s výjimkou pro minulost.
• Zda lze existující špatná data opravit na základě důkazů, místo aby se přepisovala, aby prošla.
• Kolik tření, složitosti a údržby pravidlo stojí za to.

Čistá data nepřicházejí z toho, že lidi požádáte, ať zadávají dobrá data. Přicházejí z architektury, která dělá správnou věc snadnou, špatnou těžkou a důležitá pravidla těžko obejitelnými. Příště dáme kapitolu dohromady na výřezu Steve Trucking.

K prozkoumání

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (otevře se v nové kartě) a Roll-Up Summary Field (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Picklist Limitations (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Validation Rule Considerations (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Things to Know About Duplicate Rules (otevře se v nové kartě), ověřeno 2026-10-17: limity, cesty, kde pravidla neběží, uložení přes API a import zablokovaná bez upozornění, souběžná uložení se neporovnávají.
• Apex Developer Guide, Apex Transactions (otevře se v nové kartě) a DML Statements vs. Database Class Methods (otevře se v nové kartě), ověřeno 2026-10-17: jedna transakce se vrací zpět jako celek; metody Database mohou povolit částečný úspěch.
• Salesforce Help, Workflow Rules & Process Builder End of Support (otevře se v nové kartě), ověřeno 2026-10-17.