I pole jsou architektura

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

Otázka, na kterou tento modul odpovídá: Jak by měl Salesforce fyzicky reprezentovat každý kus dat?

Vytvoření pole trvá zhruba minutu. New Field, vyberte typ, pojmenujte ho, Next, Next, Save. Právě proto se s poli nezachází jako s architekturou.

Jděte do orgu, který existuje deset let, a otevřete Account. Pět set polí. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Tři různá zákaznická čísla. Zaškrtávací políčko, které nikdo nesmaže, protože nikdo neví, která integrace ho ještě používá. Vytvoření pole trvalo minutu. Žít s ním trvá roky. Myšlenka tohoto modulu je tedy jednoduchá: pole je architektonické rozhodnutí. Ne vždycky velké, ale každé pole kóduje něco o významu, chování, identifikaci nebo kvalitě dat a stejně jako objekty se pole snadno přidávají a překvapivě těžko odstraňují.

Co tato data doopravdy znamenají?

V kapitole 2 jsme dali svým entitám atributy: doručení má plánované okno, kamion má VIN. Teď je implementujeme, a tady lidé skáčou rovnou k „textovému poli“. Počkejte. Před typem chci vědět, co data znamenají. Je to číslo, nebo identifikátor, který náhodou obsahuje číslice? Datum, nebo okamžik v čase? Volný text, nebo jedna ze schválené sady? Zadané člověkem, nebo vlastněné jiným systémem? Může se to měnit? Musí to být jedinečné? Může to chybět? Má se to vůbec ukládat, nebo počítat? To nejsou otázky na Setup. Jsou to otázky datové architektury a typ pole přijde až po odpovědi na ně.

Číslo není vždycky číslo

Steve Trucking dává každému kamionu číslo ve flotile, třeba 001247. Pole typu Number? Nejspíš ne. Sčítáme čísla ve flotile? Je kamion 1247 minus kamion 1246 jeden kamion? Je to identifikátor, který náhodou obsahuje číslice, a pole Number by dokonce zahodilo úvodní nuly. Totéž platí pro PSČ, kódy produktů, čísla účtů a čísla zásilek. To, jak hodnota vypadá, vám neříká, co znamená. Volte typ podle chování, které potřebujete, ne podle toho, jak vypadají ukázková data.

Potřebuje to člověk identifikovat?

Každý vlastní objekt dostane pole Name a prvním rozhodnutím je text, nebo automatické číslo. Ptám se: potřebuje tuto věc identifikovat člověk? Lidé znají maloobchodního partnera podle názvu a kamion podle čísla ve flotile. Ale manifest, který systém generuje každou noc? Nikdo by neměl psát „Manifest 10-02 číslo 3“ jen proto, že Salesforce vyžadoval Name. Dejte mu automatické číslo. Jen si to vygenerované Name nepleťte s identifikací záznamu: automatické číslo pomáhá uživatelům, ID Salesforce identifikuje záznam a vlastní reference manifestu od maloobchodního partnera může identifikovat stejnou věc napříč systémy. Tři různé práce.

Obrazovka podrobností

Vyberte typ, klikněte na Next a Setup se zeptá na podrobnosti. Na této obrazovce se většina rozhodnutí z tohoto modulu skutečně dělá, obvykle ve spěchu.

New Custom Field, krok 2: podrobnosti (snímek obrazovky, 2026-10-12). Plná velikost

Dvě políčka vypadají podobně a dělají různé práce. Description je pro lidi, kteří org udržují, a teď i pro nástroje AI, které ho čtou: co pole znamená, kdo ho vlastní, odkud pochází. Help Text je pro uživatele na obrazovce: co sem napsat. Vyplňte obojí. Pak přijdou Required, Unique a External ID a každé z nich si zaslouží vlastní část. Pod nimi může být Default Value vzorec, takže nový záznam může začít rozumnou hodnotou místo prázdného místa.

Required je větší rozhodnutí, než vypadá

V průvodci polem je malé zaškrtávací políčko s popiskem Required a, jak jsme viděli v kapitole 1, může být časovanou bombou. Máte objekt pět let a dva miliony záznamů a teď někdo rozhodne, že nové pole musí mít vždycky hodnotu. Co ty dva miliony záznamů, které jsou starší? Integrace, které ho neposílají? Automatizace, která záznam vytváří dřív, než je hodnota známá? Proces, kde se hodnota objeví až o tři kroky později?

„Povinné“ zní jako rozhodnutí o kvalitě dat a někdy jím je. Kdy se ale hodnota stane známou, je součástí obchodního procesu. Nezaškrtávejte tedy Required jen proto, že někdo řekne „tohle chceme vždycky“. Zeptejte se, kdy je to známé, kdo to dodává a co se stane, když to známé není. V modulu 7 to dáme na celý žebříček konzistence.

I jedinečnost něco znamená

Když označím pole jako jedinečné, dělám tvrzení o byznysu: ne „obvykle se to neopakuje“, ale „dva záznamy nikdy nesmějí mít tuto hodnotu“. To je silné. A obrazovka vás nutí rozhodnout ještě jednu věc: jsou „ABC“ a „abc“ stejná hodnota, nebo různé? Necitlivost na velikost písmen je bezpečnější výchozí volba pro cokoli, co píše člověk. Platí tu pravidlo pro klíče z kapitoly 2, jedinečný, neměnný, bez významu, nikdy osobní údaje. Když mi někdo řekne, že e-mail zaměstnance je jedinečný, začnu se ptát: může se změnit, může někdo odejít a vrátit se, mohou se adresy použít znovu, co se stane po akvizici? E-mail může být užitečný, dnes i jedinečný. To z něj nedělá dobrý identifikátor.

External ID: identifikace přes hranici

Tady si External ID vydělávají na chleba. Obrazovka to popisuje dobře: pole se stane „the unique record identifier from an external system“ (jedinečným identifikátorem záznamu z externího systému). ERP má zákazníka 873492; Salesforce má vlastní ID záznamu. Když ERP pošle aktualizaci, jak poznáme, ke kterému záznamu patří? Označte pole jako External ID a integrace podle něj může provést upsert: vytvořit záznam, pokud neexistuje, a aktualizovat ho, pokud existuje (Upsert a Record Using an External ID (otevře se v nové kartě)). A když nahráváte podřízené záznamy, můžete na nadřazený ukázat jeho External ID, místo abyste se nejdřív ptali na ID Salesforce. Rád říkám, že necháte Salesforce udělat vyhledání za vás. Velmi silné.

Všimněte si, že číslo z ERP se nestává ID záznamu v Salesforce. Je to atribut a záznam jich může nést několik: zákaznické ID z ERP, starší ID, ID partnera. To je v pořádku. Jednu obchodní entitu může několik systémů znát různě. Architektonická otázka zní, který systém vlastní který identifikátor a jaký slib dává: označte ho jako jedinečný, jen když to byznys opravdu zaručuje.

Typ pole po typu pole

Teď samotné typy. Otevřete New Field na jakémkoli objektu a Setup vám ukáže celý seznam, seskupený tak, jak ho projdu já: pole, která Salesforce počítá za vás, vztahová pole a pak datové typy.

Setup, New Custom Field, krok 1: datové typy (snímek obrazovky, 2026-10-12). Plná velikost

Tady je celý seznam na jeden pohled, s jednou věcí, kterou byste si u každého měli zapamatovat.

Skupina	Typ	Zapamatujte si
Počítaná	Auto Number	Až 30 znaků, z toho 20 předpona nebo přípona; popisek pro lidi, ne ID záznamu
	Formula	Počítá se při čtení, neukládá se; 3 900 znaků
	Roll-Up Summary	Počet, součet, minimum nebo maximum podřízených záznamů; jen master-detail
Vztahy	Lookup, Master-Detail, External Lookup	Modul 7
Data	Checkbox	Pravda, nebo nepravda, s výchozí hodnotou, kterou zvolíte; ve flow se pořád může objevit null
	Number, Percent, Currency	Pravidla zaokrouhlování; úvodní nuly se zahodí; 15 desetinných míst
	Date, Date/Time, Time	Den, okamžik, nebo denní čas; okamžiky se ukládají v UTC
	Email, Phone, URL	Formátované a kontrolované při uložení: 80, 40 a 255 znaků
	Geolocation, Address	Složená pole, která stojí víc než jedno pole: 3 a 9
	Picklist, Multi-Select	Řízený slovník, který vlastní administrátor
	Text, Text Area, Long, Rich, Encrypted	Do 255 na záznamu a indexovatelné; nad tím bez indexu a filtrování

Pole, která Salesforce počítá

Auto Number přiřadí každému novému záznamu další číslo v řadě, ve formátu, který definujete, třeba T-{000000}. Použijte ho, když člověk potřebuje přívětivý úchyt a nikdo by si ho neměl muset vymýšlet. Celá hodnota má až 30 znaků a 20 z nich je vyhrazeno pro předponu nebo příponu. Jen si pamatujte z kapitoly 2: je to popisek pro lidi, ne ID záznamu, a čísla nejsou vždycky striktně po sobě jdoucí.

Pole Formula počítají hodnotu z jiných polí. Jsou silná a počítají se při čtení záznamu, ne při uložení, takže není nic uloženého, co by mohlo zastarat. Volíte, co vzorec vrací: checkbox, měnu, datum, datum/čas, číslo, procento, text nebo čas.

New Custom Field, vzorec: volba návratového typu (snímek obrazovky, 2026-10-12). Plná velikost

Pak napíšete samotný vzorec, s poli, operátory a funkcemi, a zkontrolujete jeho syntaxi. Všimněte si tlačítka Use Formula Assistant: AI od Salesforce vám teď se vzorcem pomůže. Použijte ji a pak si přečtěte, co napsala. Vzorec vlastníte vy, ne asistent.

Editor vzorců s asistentem Formula Assistant (snímek obrazovky, 2026-10-12). Plná velikost Vzorec může mít až 3 900 znaků a při uložení nebo kompilaci nesmí přesáhnout 15 000 bajtů; dlouhý vzorec lze rozdělit do několika polí se vzorci, která na sebe odkazují. Dlouhé textové oblasti, šifrovaná pole a pole Description v nich použít nelze.

Pole Roll-Up Summary sedí na hlavním záznamu a počítají, sčítají nebo berou minimum či maximum jeho podřízených záznamů. Fungují jen přes vztah master-detail, což je jeden z největších důvodů vůbec master-detail zvolit. Vrátíme se k nim, i k jejich limitům, v modulu 7.

Uložené, nebo odvozené?

Potřebujeme tuto hodnotu vůbec ukládat? Pokud mám množství a jednotkovou cenu, musí někdo, nebo nějaká automatizace, udržovat celkovou částku? Možná by ji měl odvodit vzorec: jeden zdroj výpočtu, přepočítaný při čtení, takže změňte množství a odpověď se přizpůsobí. Vzorce mají vlastní limity (velikost při uložení a zobrazovaná délka; Formula Field Limits and Restrictions (otevře se v nové kartě)) a složité vzorce se těžko udržují.

Někdy ale byznys nechce dnešní odpověď. Chce odpověď takovou, jaká byla. Pokud se příští rok změní pravidlo slev, má loňská faktura najednou ukazovat jinou částku? Samozřejmě ne. Otázka tedy nezní „umí to Salesforce spočítat?“ Zní „je to aktuální výpočet, nebo historický fakt?“ Historické fakty se ukládají.

Vztahová pole

Vztahy Lookup, Master-Detail a External Lookup jsou také pole a právě v nich se čáry vašeho modelu stávají skutečnými. Lookup je volná vazba; master-detail váže život, vlastnictví a zabezpečení podřízeného záznamu na nadřazený; externí lookup dosáhne na externí objekt z modulu 4 párováním podle jeho External ID. Volba mezi nimi je dost velké rozhodnutí na to, aby dostala vlastní modul.

Checkbox

Checkbox (zaškrtávací políčko) je nejjednodušší pole, jaké existuje: pravda, nebo nepravda, zaškrtnuto, nebo nezaškrtnuto. Je ideální pro fakt ano/ne o záznamu: Is Active, Install Required, Signed For. Když ho vytváříte, Salesforce vás nutí zvolit jeho výchozí hodnotu, zaškrtnuto, nebo nezaškrtnuto, a to je skutečné rozhodnutí: s tou začíná každý nový záznam, včetně záznamů, které vytvoří integrace, aniž by pole poslala. Sestavy a zobrazení seznamů ho filtrují jako True a False; nástroje pro import a týdenní export ho ukazují jako 1 a 0.

Jedna past, kterou je dobré znát. Pole na záznamu má dvě hodnoty, ale automatizace kolem něj může mít třetí. Ve flow je proměnná checkbox, která nikdy nebyla nastavená, null, ne false, a její uložení do záznamu selže (Trailblazer Community (otevře se v nové kartě); viz také známý problém Salesforce W-11208535 (otevře se v nové kartě)). Zvolte rozumnou výchozí hodnotu a ve flow i v kódu zacházejte s null záměrně.

Number, Percent a Currency

Number ukládá reálné číslo a zahazuje úvodní nuly, a právě proto číslo ve flotile jako 001247 není Number. Salesforce zaokrouhluje číselná pole na polovinu směrem od nuly: z 12,345 je 12,35 a z −12,345 je −12,35. A ve slučovacích polích zaokrouhluje podle národního prostředí uživatele, ne podle desetinných míst nastavených u pole.

Percent ukládá desetinné číslo a zobrazuje procento: zadejte 0,10 a uvidíte 10 %. Hodnoty ztrácejí přesnost po 15 desetinných místech.

Currency je formátovaná pro peníze a v orgu s více měnami nese kód měny a může používat směnné kurzy; s pokročilou správou měn (otevře se v nové kartě) mohou příležitosti používat datované směnné kurzy, kurz pro období, ve kterém se obchod uzavřel. Datované kurzy používají jen příležitosti a věci kolem nich (produkty, rozpisy, rozdělení a jejich sestavy); měnová pole na jiných objektech si drží jediný statický kurz. Pozor na zaokrouhlování: bez desetinných míst Salesforce prostě usekne (z 23,5 je 23); s jedním a více zaokrouhluje na polovinu směrem od nuly.

Date, Date/Time a Time

Tři typy, tři různé významy. Date je den: smlouva vyprší k datu. Date/Time je okamžik: doručení dorazilo ten den v 9:42 ráno. Time je denní čas úplně bez data: prodejna otvírá v 7:00, každý den.

Pastí je okamžik. Salesforce ukládá hodnoty datum/čas v GMT (UTC). Čas, který uživatel napíše, se přečte v jeho časovém pásmu, převede a uloží; když ho někdo čte, převede se znovu do časového pásma čtenáře. Většinou je to přesně to, co chcete. Tady je ale příklad, který dávám ve třídě: dispečerka v Los Angeles zapíše doručení pozdě v neděli večer, ve 22:00 tichomořského času. Pod tím Salesforce uložil pondělí ráno, 5:00 GMT. Sestava seskupená podle dne v jiném časovém pásmu nebo integrace, která čte surovou hodnotu, může to nedělní doručení dát na pondělí. „Den, kdy se to stalo“ závisí na tom, čích hodin se zeptáte. Hlídejte časová pásma uživatelů a rozhodněte, které z nich byznys myslí.

A buďte opatrní při porovnávání. Pod tím je datum/čas jedno velké číslo: Apex ho čte jako počet milisekund od 1. ledna 1970, 00:00:00 GMT (Datetime Class (otevře se v nové kartě)). Je to přesný okamžik, ne den. Otázka, jestli jsou dvě hodnoty datum/čas rovné (==), tedy téměř nikdy nedělá, co chcete: 9:42:00 a 9:42:01 rovné nejsou a stejně tak „pondělí“ a jakýkoli okamžik v pondělí. Místo toho se ptejte na rozsah: od začátku včetně (>=) do konce včetně (<=). „Každé doručení v pondělí“ je každé doručení >= pondělí 00:00 a <= pondělí 23:59:59, v časovém pásmu, o kterém jste rozhodli, že ho byznys myslí.

A jedna zábavná: Salesforce neumí uložit jakékoli datum. Platná data jsou od 1. ledna 1700 do 31. prosince 4000 a Salesforce uvádí stejný rozsah pro data i hodnoty datum/čas (Data Import Dates (otevře se v nové kartě)). I hranice jsou okamžiky v GMT, takže pro uživatele v tichomořském čase je nejdřívější platná hodnota 31. prosince 1699 v 16:00. Datum založení vašeho vlastivědného spolku se tam možná nevejde. A klasický trik „bez data konce“, 31. prosince 9999, se odmítne; pokud potřebujete zástupnou hodnotu ve vzdálené budoucnosti, musí být v roce 4000 nebo dřív.

Email, Phone a URL

To jsou formátovaná pole a dělají víc než jen ukládání znaků. Email pojme až 80 znaků a kontroluje se správný formát; u kontaktů a zájemců kliknutí na něj zahájí e-mail na tu adresu. Phone pojme až 40 znaků, formátuje se jako telefonní číslo a stane se klikni a vytoč, když má org připojený telefonní systém. URL pojme až 255 znaků a otevírá se jako odkaz. To vám platforma dává chování zadarmo, a proto bych telefonní číslo nikdy neukládal do prostého textového pole.

Kontrolují se i integrace. Hodnota, která neodpovídá formátu pole, třeba špatně utvořená e-mailová adresa, neprojde ověřením a odmítne se celý záznam, ne jen to pole. Když jsou tedy data zdrojového systému chaotická, vyčistěte je, než dorazí, nebo počítejte se záznamy, které se nenahrají.

Geolocation a Address

Geolocation drží zeměpisnou šířku a délku. Pod tím je pole jménem Location__c ve skutečnosti dvě hodnoty, které můžete číst a nastavovat samostatně, Location__Latitude__s a Location__Longitude__s. A můžete se na něj dotazovat: funkce SOQL DISTANCE a GEOLOCATION najdou záznamy v okruhu nebo je seřadí podle vzdálenosti. „Každé otevřené doručení do 25 mil od tohoto kamionu“ je jeden dotaz: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (otevře se v nové kartě)). Address drží celou adresu, ulici, město, stát nebo provincii, PSČ a zemi, a uživatelé mohou adresu vyhledat a nechat si části vyplnit.

Obě jsou složená pole: jedno pole na obrazovce, několik pod ním. A do limitu vašeho objektu se počítají víc než jako jedno pole: Geolocation se počítá jako tři vlastní pole a Address jako devět. Na objektu, který je už přeplněný, na tom záleží.

Picklist a Multi-Select

Výběrový seznam (picklist) řídí, co uživatelé mohou zadat: jednu hodnotu ze seznamu, který definujete. Stav? Nejspíš výběrový seznam. Hodnoty jsou ale metadata a přidat nebo změnit je musí administrátor. Pořád se tedy ptám, kdo hodnoty vlastní, jak často se mění, jestli stejný seznam potřebuje několik objektů, jestli hodnoty nesou vlastní informace a jestli slovník nevlastní jiný systém.

I to, kde hodnoty žijí, je rozhodnutí. Když se seznam používá jednou, na jednom poli, nechte hodnoty přímo na poli, na objektu; to Salesforce dělá ve výchozím stavu. Když se ale stejná sada hodnot začne objevovat na několika místech, region na účtu, na doručení a na skladu, povyšte ji na globální sadu hodnot dřív, než se kopie rozejdou. Globální sada hodnot (global value set) drží jeden seznam pro všechny, až 1 000 hodnot, aktivních i neaktivních dohromady (Picklist Limitations (otevře se v nové kartě)). Vlastní popis v Setupu říká, proč na tom záleží: sada hodnot „is restricted so users can’t add unapproved values through the API“ (je omezená, takže uživatelé nemohou přes API přidávat neschválené hodnoty). Jeden seznam, jeden vlastník a žádná integrace, která by propašovala nový pravopis.

Ten poslední bod je rozdíl mezi omezeným (restricted) a neomezeným (unrestricted) seznamem. U omezeného výběrového seznamu jsou povolené jen hodnoty, které definoval administrátor, odkudkoli: uživatel, import nebo integrace, která pošle cokoli jiného, dostane chybu „bad value for restricted picklist field“ a záznam se neuloží. U neomezeného výběrového seznamu uživatelé na obrazovce pořád vybírají ze seznamu, ale API, importy a automatizace mohou poslat jakoukoli hodnotu a Salesforce ji uloží a přidá jako neaktivní hodnotu (Picklist Limitations (otevře se v nové kartě); Create a Custom Picklist Field (otevře se v nové kartě)). Tak org skončí s „Delivered“, „delivered“ a „Dlvrd“. Globální sady hodnot jsou vždycky omezené. Moje výchozí volba je omezený; neomezený je záměrná volba pro případ, kdy hodnoty opravdu vlastní jiný systém, a pak někdo vlastní úklid těch neaktivních.

Setup, Picklist Value Sets: nová globální sada hodnot (snímek obrazovky, 2026-10-12). Plná velikost

Výběrový seznam s více hodnotami (multi-select picklist) umožňuje uživateli vybrat několik hodnot, uložených dohromady a oddělených středníky. Pohodlné na obrazovce, nešikovné všude jinde: hůř se podle něj filtruje, dělají sestavy a integruje a nedá se použít ve filtru souhrnného pole. Několik hodnot pro jeden záznam obvykle znamená poučení z kapitoly 2: ven se dere podřízený objekt.

Výběrový seznam má také o jednu hodnotu víc, než kolik jste jich definovali: prázdnou. Záznam může zůstat bez výběru a to lidi chytá. Ve vzorci nebo ověřovacím pravidle nemůžete výběrový seznam testovat samotnou funkcí ISBLANK; píšete ISBLANK(TEXT(Field__c)), nebo ISPICKVAL(Field__c, "") (Trailblazer Community (otevře se v nové kartě)). Rozhodněte tedy u každého výběrového seznamu, co znamená „žádná hodnota“: je povolená a co znamená, když nastane? Pak to nechte řešit své vzorce, ověřovací pravidla a filtry.

A někdy je atribut ve skutečnosti entita. Někdo chce výběrový seznam distribučních center. Je jich devět. Snadné. Pak se dozvíme, že každé má adresu, vedoucího, provozní dobu, kapacitu, region a kamiony. To není výběrový seznam; to je věc. Nedělejte z entity výběrový seznam jen proto, že jich zatím není moc. V prvním roce je to skvělé a v pátém hrozné. (Modul 5 kapitoly 2 má moje orientační pravidla, kdy si seznam zaslouží vlastní objekt.)

Textová rodina

Text učím jako dva druhy a hranice mezi nimi je 255 znaků.

Do 255: uloženo se záznamem. Text pojme až 255 znaků a můžete ho použít skoro všude: ve vzorcích, filtrech, sestavách, zobrazeních seznamů, jako jedinečné pole nebo External ID, a dá se indexovat. Text Area pojme také 255, na samostatných řádcích, jako krátká poznámka.

Nad 255: uloženo odkazem. Text Area (Long) pojme až 131 072 znaků a Text Area (Rich) totéž s formátováním, odkazy a obrázky. Představuji si je jako uložené stranou, se záznamem, který drží ukazatel, a tak se i chovají: žádný index, takže z nich nemůžete udělat jedinečné pole ani External ID; nemůžete podle nich filtrovat v klauzuli SOQL WHERE (SOQL WHERE (otevře se v nové kartě)); vzorce je nemohou používat (Formula Field Limits and Restrictions (otevře se v nové kartě)); a sestavy u vlastního pole ukazují jen prvních 254 znaků a filtry sestav prohledávají jen zhruba prvních 255 (Filter Restrictions for Text Area (Long) Fields (otevře se v nové kartě)). Obrázky nahrané do pole s formátovaným textem mohou mít každý až 1 MB a počítají se do úložiště souborů, zatímco text se počítá do úložiště dat (Rich Text Area Field Considerations (otevře se v nové kartě)). Pokud tedy kdokoli potřebuje podle hodnoty hledat, řadit, párovat nebo nad ní dělat sestavy, držte ji pod 255 a nechte ji polem Text.

Text (Encrypted) ukládá až 175 znaků v šifrované podobě, pomocí Classic Encryption. Pokud váš org používá Shield Platform Encryption, šifrujete místo toho obyčejné pole Text a tímto způsobem lze šifrovat i mnoho dalších typů.

Dejte každému poli popis

Můj standard: každé pole dostane popis. Věřím tomu dlouho a v době AI na tom záleží víc než kdy dřív: každý nástroj AI a agent, který čte váš org, čte popisy, aby pochopil, co pole znamená. Prázdný popis je odhad, který čeká, až se stane. Co znamená Customer_Status__c? Kdo ho vlastní? Odkud pochází? Mohou ho uživatelé upravovat, nebo ho dnes v noci přepíše ERP? Za šest měsíců si to nebudu pamatovat a za tři roky to administrátor, který bude org udržovat, nebude vědět, pokud jsme mu to neřekli. Popisek není dokumentace a název API také ne.

Na hodně sdílených objektech (Account, Contact, Opportunity) používám u specializovaných polí také předpony v názvech, aby byl jejich původ a účel vidět přímo v názvu: všechno, co vlastní ERP, začíná například stejnou předponou. Nejde mi o dvanáctislovné názvy API. Chci, aby se model vysvětloval sám.

Klasifikujte, na čem záleží: taxonomická pole

Salesforce dává každému poli sadu klasifikačních metadat. Říkám jim taxonomická pole. Můžete zaznamenat vlastníka dat (data owner); použití pole (Field Usage: Active, DeprecateCandidate, Hidden); úroveň citlivosti dat (Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical); a kategorizaci souladu (Compliance Categorization): PII, HIPAA, GDPR, PCI, CCPA a další. Fungují na standardních polích stejně jako na vlastních (Data Classification Metadata Fields (otevře se v nové kartě)).

Proč se s tím obtěžovat? Protože je procesy umí číst. Označte pole jako GDPR a proces dokáže najít každé pole GDPR na záznamu a zamaskovat ho nebo odstranit. A když vrstva důvěry Salesforce (trust layer) posílá prompt velkému jazykovému modelu, může přesně tuto klasifikaci použít k maskování citlivých polí: jméno zákazníka, třeba „Maria Lopez“, cestou ven vymění za zástupný znak, model jméno nikdy neuvidí a cestou zpět se jméno do odpovědi vrátí (Einstein Trust Layer (otevře se v nové kartě)).

Aktualizace. Salesforce teď dokumentuje, že maskování podle vzorů a podle polí pro LLM je u agentů vypnuté: maskování může odstranit kontext, který agent k odpovědi potřebuje (Data Masking Limitations in Agentforce (otevře se v nové kartě)). Klasifikace pořád řídí maskování u jiných funkcí generativní AI, ale nespoléhejte na ni, že udrží osobní údaje mimo dosah agenta; to je rozhodnutí o přístupu a návrhu (kapitola 12).

Můj postoj: klasifikace je důležitá v klíčových chvílích. Nedělejte z ní tři týdny vyplňování každého políčka jen proto, že to řekl tým správy dat. Používejte ji tam, kde na tom záleží: osobní údaje, finanční údaje, regulovaná data a pole, kde byznys potřebuje jmenovaného vlastníka. Jde o to, aby citlivost přestala být znalostí v něčí hlavě a stala se součástí pole.

Nad rámec zkoušky: co mění AI. Špatná dokumentace polí dřív trestala dalšího administrátora. Teď mate každý nástroj AI a agenta, který čte schéma: je Flag2__c citlivé, autoritativní, ještě používané? AI také vytváří pole rychleji než jakýkoli tým, takže názvy, popisy a klasifikace jsou součástí architektury, ne úklidu.

Každé pole je závazek

Jakmile pole sbírá data, všechno se o něj začne opírat. Obrazovky ho ukazují, flow se podle něj větví, ověřovací pravidla ho kontrolují, sestavy podle něj seskupují, integrace ho posílají a čtou a teď o něm uvažují i nástroje AI. Každý z nich si o poli dělá předpoklady: o jeho typu, délce, jestli je někdy prázdné a co znamenají jeho hodnoty. Změňte pole později a musíte nejdřív najít každý z těch předpokladů. Přejmenování hodnoty výběrového seznamu, zkrácení textového pole nebo změna pole Text na výběrový seznam zní jako malá změna, a může rozbít integraci v systému jiné firmy. Proto je pole závazek.

Kliknutím zvětšíte

Nechci, abyste z tohoto modulu odcházeli s obavou vytvářet pole. Salesforce je postavený tak, aby se rozšiřoval; využijte to. Chci, aby se otázka změnila z „jaký typ pole mám vybrat?“ na „co tato data znamenají a k jakému chování se zavazujeme?“ Typ, povinnost, jedinečnost, External ID, výběrový seznam, vzorec, popis, klasifikace: dohromady jsou fyzickým vyjádřením logického modelu z kapitoly 2.

Co tady rozhoduje architekt

• Co hodnota znamená, dřív než zvolíme typ pole, a zda jde o atribut, identifikátor, řízený slovník, nebo ve skutečnosti o další entitu.
• Zda je hodnota aktuální výpočet, který lze odvodit, nebo historický fakt, který se musí uložit.
• Který systém vlastní který identifikátor a zda je jeho jedinečnost skutečným obchodním slibem.
• Kdy je povinná hodnota skutečně známá a co se stane se záznamy a integracemi, které ji nemají.
• Jaký popis, pojmenování a klasifikaci pole potřebuje, aby ho lidé, procesy i AI mohli bezpečně používat.

K prozkoumání

• Salesforce Help, Data Classification Metadata Fields (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Help, Einstein Trust Layer: Designed for Trust (otevře se v nové kartě) a Data Masking Limitations in Agentforce (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (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, Formula Field Limits and Restrictions (otevře se v nové kartě), ověřeno 2026-10-17.
• Salesforce Developers, Date Formats and Date Literals (otevře se v nové kartě), ověřeno 2026-10-17.