Standardní datové modely

🌐 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 2 z 10 kapitoly Datová architektura Salesforce, kapitoly 3 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Datová platforma Salesforce: víc než databáze · Další: Postavte si vlastní: vlastní objekty

Otázka, na kterou tento modul odpovídá: Co už pro vás Salesforce namodeloval a jak je to poskládané?

V modulu 1 jsem vám řekl, ať se díváte na mateřskou loď: než něco vymyslíte, podívejte se, jak to dělá Salesforce sám. V tomto modulu se skutečně díváme. Salesforce už pro vás namodeloval spoustu byznysu ve svých standardních objektech a dva z těch modelů dělají většinu práce ve většině orgů, do kterých přijdu: prodejní model a servisní model. Než můžete rozhodnout, jestli si něco zaslouží vlastní objekt, potřebujete vědět, co už tam je. To jsou dva následující moduly.

Co dělá objekt standardním

Standardní objekt je k dispozici hned po instalaci. Postavil ho Salesforce, má definovaný účel a přichází s vlastními poli a vztahy. Můžete do něj přidávat pole, stavět kolem něj automatizaci a měnit jeho rozvržení, ale nemůžete ho přenavrhnout: standardní pole a vztahy patří Salesforce.

Podívejte se na názvy. Account, Contact, Case. Žádná předpona, žádná přípona. Tak si Salesforce drží tento prostor pro sebe. Všechno, co postavíme my, končí na __c, takže Salesforce může kdykoli přidat nové standardní objekty, aniž by se kdy srazil s čímkoli ve vašem orgu. A dělá to, s každým vydáním.

Někdy v minulosti kdosi postavil produktový objekt, který se neosvědčil a musel se nechat za sebou. Proto je název API Product2. Je to můj první lakmusový test, když mi někdo řekne, že Salesforce zná.

Prodejní model

Začněte vlevo, zájemcem (Lead): někým, kdo se může stát zákazníkem. Zájemce ještě doopravdy není součástí modelu. Je to čekárna. Když ho převedete, Salesforce vytvoří skutečné záznamy: účet (Account), kontakt (Contact) a pokud jde o obchod, příležitost (Opportunity). Proto zájemce kreslím stranou.

Účet je firma. Jeho kontakty jsou lidé v ní. Příležitost je obchod s tímto účtem. Zatím nic, co byste nečekali.

Pak to začne být zajímavé. Co je v obchodu? Každý řádek je produkt příležitosti (Opportunity Product) a produkt příležitosti neukazuje přímo na produkt. Ukazuje na položku ceníku (Price Book Entry): tento produkt, za tuto cenu, v tomto ceníku. Položka ceníku sedí mezi produktem (Product) a ceníkem (Price Book), takže stejný produkt může mít jednu cenu ve standardním ceníku a jinou ve vašem partnerském ceníku.

To jsou dva vztahy, které se staly věcmi, jeden po druhém. Vzpomínáte na položku doručení z kapitoly 2, mezi doručením a produktem, a na Trik psa mezi Psem a Trikem? Salesforce tu udělal přesně totéž, dvakrát: produkt příležitosti mezi příležitostí a položkou ceníku a položku ceníku mezi produktem a ceníkem. Když tohle umíte přečíst, umíte přečíst většinu standardního datového modelu.

Kliknutím zvětšíte

Tady je ten řetězec zblízka, s poli, která ho drží pohromadě:

Kliknutím zvětšíte

Jedno pravidlo, na kterém lidé klopýtají: existuje standardní ceník a položka ceníku v jakémkoli jiném ceníku může jednoduše použít standardní cenu produktu. Než nahrajete produkty příležitosti, vězte, který ceník používá.

Servisní model

Teď druhá strana domu. Stejný účet, stejné kontakty. Když se něco pokazí, zákazník otevře případ (Case).

Případ je obvykle o něčem, co zákazník má, a Salesforce pro to má objekt: majetek (Asset). V modulu 5 ho nazvu standardním objektem, který lidé přehlížejí. Je to věc, kterou zákazník má, ať ji koupil od vás, nebo ne.

A na co má zákazník nárok? To je nárok (Entitlement): podpora, kterou může účet dostávat, často navázaná na majetek, produkt nebo servisní smlouvu. Dejte nárok na případ a případ teď ví, jakou úroveň podpory má dostat.

Kliknutím zvětšíte

Podívejte se na čáru, která vede od případu zpátky k němu samotnému. Každý případ má pole Parent Case (nadřazený případ) a to ukazuje na jiný případ. To je lookup sám na sebe (self-lookup): vztah objektu k sobě samému. Spoustu lidí poprvé zmate, takže tady jsou dva důvody, proč ho používám.

Zaprvé: velký problém, který se rozpadne na menší. Zákazník nahlásí, že nefunguje celá instalace. Otevřeme dílčí případy pro síť, hardware a konfiguraci, každý se řeší samostatně a všechny se vyřeší směrem nahoru: nadřazený případ není hotový, dokud nejsou hotové ony.

Zadruhé: historie. Případ byl uzavřen minulý měsíc a teď se stejný problém vrátil. Nový případ ukazuje zpět na ten původní, takže každý, kdo ho otevře, vidí, že se to už stalo, a co se s tím udělalo.

K lookupům sám na sebe se vrátíme, až se v modulu 7 dostaneme ke vztahům.

Všimněte si, že účet a kontakt sedí v obou diagramech na stejném místě. Jsou to stejné záznamy. Obchodník a servisní agent se dívají na stejného zákazníka, z různých stran domu. To je jeden z nejsilnějších argumentů pro to zůstat u standardu: modely byly postavené tak, aby se potkaly.

Soubory a přílohy

Ne všechno na záznamu je pole. Smlouvy, fotky, PDF a tabulky jsou soubory a patří do Salesforce Files, ne do starého modelu Attachments, který je zastaralý. Pokud dokument už žije v SharePoint Online, OneDrive, Google Drive nebo Box, umožní Files Connect uživatelům dostat se k němu ze Salesforce, aniž by se kopíroval dovnitř.

Soubory se počítají jinak než záznamy. Salesforce dělí úložiště na dvě: úložiště souborů obsahuje přílohy, Files, Salesforce CRM Content, soubory Chatteru a podobně a úložiště dat obsahuje vaše záznamy. Úložiště souborů rychle roste, když každý záznam dostává fotky nebo skeny, takže velké objemy obrázků, jako fotky z terénní aplikace, často patří úplně mimo Salesforce a Salesforce si drží jen odkaz. Modul 4 se k tomu vrací.

Dva sloupce, nebo dvě stě

I úložiště dat se počítá jinak než v databázi. V běžné databázi je tabulka se dvěma sloupci a milionem řádků malá a tabulka se stovkou sloupců a milionem řádků je slon. Salesforce je váží stejně: většina záznamů se počítá zhruba jako 2 KB bez ohledu na to, kolik mají polí. Existují výjimky. Kampaň se počítá víc, e-mailová zpráva podle skutečné velikosti a osobní účet zhruba jako 4 KB, protože je to účet i kontakt.

Tady je tip. Kdykoli přijdu do nového orgu, jedno z prvních míst, kam jdu, je Setup → Storage Usage. Klienta dokonce požádám o snímek obrazovky už na prvním hovoru. Ta obrazovka nelže. Řekne vám, které objekty rostou a které už jsou sloni.

Osobní účty: když je zákazníkem člověk

Model účtů a kontaktů funguje nádherně pro firmu a lidi v ní. Ale co když vaším zákazníkem není firma? Co když je to člověk?

To je osobní účet (person account): účet a kontakt spojené do jednoho záznamu, pro jednotlivé lidi. Jejich kontaktní pole přicházejí s nimi a ta vlastní se objevují s vlastní příponou, __pc. Každý se počítá do úložiště účtů i kontaktů, protože pod tím je obojím.

Jedno varování, než je zapnete: jakmile jsou osobní účty povolené, nelze je zakázat. To je test vratnosti z kapitoly 1 v nejčistší podobě. Modul 5 vám dá můj postoj k tomu, kdy za to stojí.

Co tady rozhoduje architekt

• Které části byznysu už Salesforce namodeloval, dřív než se navrhne cokoli nového.
• Zda pojem patří do prodejního modelu, do servisního modelu, nebo do obou, s vědomím, že sdílejí účet a kontakt.
• Kde žijí dokumenty a obrázky: v Salesforce Files, v připojeném souborovém systému, nebo mimo platformu s odkazem.
• Kolik budou data stát na úložišti, počítáno tak, jak to počítá Salesforce: záznamy, ne sloupce.
• Zda je zákazníkem firma, nebo člověk, dřív než zapnete něco, co nejde vypnout.

A když Salesforce nemá, co potřebujete? Postavíte si to. To přijde příště.

K prozkoumání

• OpportunityLineItem (otevře se v nové kartě), Object Reference for the Salesforce Platform (ověřeno 2026-10-17): „a member of the list of Product2 products associated with an Opportunity“ (položka seznamu produktů Product2 přidružených k příležitosti); položka ceníku je povinná.
• PricebookEntry (otevře se v nové kartě), Object Reference (ověřeno 2026-10-17): „an association between a Pricebook2 and Product2“ (přiřazení mezi Pricebook2 a Product2); položka může použít standardní cenu.
• Case (otevře se v nové kartě), Object Reference (ověřeno 2026-10-17): ParentId, „the ID of the parent case in the hierarchy. The label is Parent Case“ (ID nadřazeného případu v hierarchii; popisek je Parent Case); lookup na Case.
• Entitlement (otevře se v nové kartě), Object Reference (ověřeno 2026-10-17): „the customer support an account or contact is eligible to receive“ (zákaznická podpora, na kterou má účet nebo kontakt nárok), případně na základě majetku, produktu nebo servisní smlouvy.
• Data and Storage Resources (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): co zahrnuje úložiště souborů a úložiště dat.
• Salesforce Data Storage: Estimated Record Size by Object Type (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): „Most Salesforce records consume approximately 2 KB of data storage“ (většina záznamů Salesforce zabírá přibližně 2 KB úložiště dat); osobní účty asi 4 KB.
• Enable Person Accounts (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): „After Person Accounts is enabled, it can’t be disabled.“ (Jakmile jsou osobní účty povolené, nelze je zakázat.)
• Files Connect FAQ (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17).