Zvolte správný objekt

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

Otázka, na kterou tento modul odpovídá: Jakým druhem objektu Salesforce se má tento obchodní pojem stát a co dovolují licence?

Jedna z nejsnazších věcí v Salesforce je vytvořit vlastní objekt. Právě proto si myslím, že jich vytváříme příliš mnoho.

Jste na sezení k požadavkům a někdo řekne: „Potřebujeme sledovat naše distributory.“ Nový vlastní objekt: Distributor. Hotovo. Až na to, že chci, aby se architekt nejdřív zeptal jinak: co je distributor? Je to firma. Salesforce už má docela dobrý způsob, jak firmu reprezentovat. Jmenuje se účet (Account). To neznamená, že odpovědí je vždycky účet. Pokud ale musím vysvětlovat, proč firma není účet, chci lepší důvod než „byznys jim říká distributoři“.

Tady se logický model z kapitoly 2 potkává s platformou a můj výchozí postoj je jednoduchý: pokud obchodní pojem čistě sedí na zamýšlený účel standardního objektu, začněte tam.

Začněte významem

I když si něco zaslouží být objektem, nezaslouží si automaticky být vlastním objektem. Zeptejte se, co ta věc doopravdy reprezentuje. Firmu nebo organizaci jakékoli formy? Začněte účtem. Osobu, která s tou organizací pracuje? Kontakt. Něco, co zákazník vlastní nebo koupil? Majetek (Asset). Něco, co se snažíte prodat? Teď do rozhovoru patří příležitost (Opportunity).

Proto jsme se nejdřív dívali na mateřskou loď, v modulu 2. Ty modely nesedí na každý byznys, ale neměli bychom je ignorovat jen proto, že vlastní stavba působí čistěji. Před New Custom Object se zeptejte, jak Salesforce tento pojem modeluje, co kolem toho modelu už je postavené a čeho byste se vzdali, kdybyste ho nahradili.

Test čistého souladu

Můj test je jedna otázka: sedí tento obchodní pojem čistě na zamýšlený účel standardního objektu? Pokud ano, přikláním se ke standardnímu objektu.

Distributor je firma, se kterou máme vztah, takže účet čistě sedí. Nevadí mi, že uživatelé jedné firmě říkají distributor, jiné dodavatel, další maloobchodní partner a další zákazník. To jsou obchodní role a nepotřebují čtyři fyzické objekty. Různé obchodní názvy automaticky neznamenají různé datové struktury. Rozdíl může nést typ, typ záznamu nebo vztah.

Test funguje i opačným směrem. V kapitole 1 jsem vám nechal otázku: firma zákazníka má mnoho míst doručení. Má být každé místo účtem, nebo vlastním objektem?

Účet vám dává hodně. Dostanete pole adresy a všechno, co už adresu účtu očekává: sestavy, mapy, integrace. Dostanete ale i režii: spoustu polí, sdílení, hierarchii, vlastnictví, všechno, co na účtu visí, a většina z toho pro samostatnou adresu není relevantní. Nesli byste spoustu těžkých věcí, které nevyužijete, jen kvůli alternativní adrese.

Vlastní objekt, podřízený účtu, může být lehký: jen pole adresy, místo, kam doručujeme, s vlastním životním cyklem, který můžu řídit nezávisle.

Je to tedy rovnováha: váha, kterou na sebe berete, proti hodnotě, kterou získáte. Pokud potřebuji jen adresu s vlastním životním cyklem, tam jdu na vlastní objekt.

Stejně je to s dílčími problémy u případu. Pokud je každý dílčí problém opravdu případ, řešený agentem, s vlastním stavem a úrovní služeb, zanořte je pomocí Parent Case z modulu 2. Pokud je to ale jen položka kontrolního seznamu, kterou nikdo jako případ neřeší, nese plný případ spoustu toho, co nikdy nevyužije, a jednoduchý vlastní podřízený objekt může vážit méně. Ne proto, že by vlastní byl čistší. Protože význam je jiný, nebo je váha špatná.

Standardní objekty přicházejí se zavazadly

Když volíte standardní objekt, volíte víc než jeho pole. Volíte něco, čemu už produkty Salesforce rozumějí: sestavy, automatizaci, vestavěné vztahy, produktové funkce, balíčky z AppExchange a cokoli, co Salesforce postaví příště. To může mít obrovskou hodnotu.

Standardní objekty mají ale i své názory: existující chování, vztahy, bezpečnostní úvahy, někdy licenční požadavky a funkce, které nepotřebujete. „Vždycky používejte standardní objekty“ tedy není moje pravidlo. Žádné pravidlo „vždycky“ nemám. Mám sklon: použijte standardní objekt, když význam čistě sedí a chování platformy kolem něj návrhu pomáhá, místo aby proti němu bojovalo. Pokud pět let ohýbám příležitost, aby se chovala jako něco, co není obchodní příležitost, nezískal jsem tím, že jsem zůstal u standardu, nic. Jen jsem udělal špatný kompromis opačným směrem.

Majetek je dobrý příklad

Majetek (Asset) je jeden ze standardních objektů, které lidé přehlížejí. Nejjednodušeji to řeknu takhle: je to věc, kterou zákazník má. Možná ji koupil od nás, možná ne. I na produktu konkurence, který stojí u mého zákazníka, mi záleží, protože ho servisuji, nebo se ho snažím nahradit, nebo potřebuji rozumět jeho instalované základně. Pokud vytvořím Customer_Product__c, aniž bych se nejdřív podíval na Asset, přeskočil jsem architektonickou otázku. Asset automaticky nevyhrává, ale zaslouží si, aby se zhodnotil.

Osobní účty: kdy je osoba účtem?

V modulu 2 jsme potkali osobní účty: účet a kontakt v jednom záznamu, pro zákazníky, kteří jsou jednotlivci. Teď rozhodnutí.

Můj postoj: pro B2C se bez nich těžko obejdete. S účty a kontakty přichází hned po instalaci tolik, že náklady a režie za to stojí. A náklady tu jsou: zhruba dvojnásobné úložiště oproti firemnímu účtu, přepínač, který nejde vypnout, a některé externí licence je používat nemohou. Partner Community nelze s osobními účty použít (Experience Cloud User Licenses (otevře se v nové kartě)). Otázka tedy nezní „máme v databázi lidi?“ Lidi má každý org. Zní „je osoba v tomto byznysu skutečně účtem?“ To, že je kontakt osoba, z něj nedělá osobní účet. Dělá to obchodní vztah.

Kliknutím zvětšíte

A teď všechno zkomplikuji: licence

Zatím: najděte pojem, hledejte nejčistší standardní soulad, jděte na vlastní objekt, když význam nesedí. Teď architektova další otázka: kdo to potřebuje používat? Můžete navrhnout krásný model a pak zjistit, že polovina lidí, kteří data potřebují, nemá licenci na objekty, které jste zvolili. Licence jsou součástí datového modelu.

Tři interní licence

Začněte vlastními lidmi. Uvnitř firmy jsou tři typy licencí, které chci, aby každý architekt znal nazpaměť, protože řídí, co každý uživatel vidí a smí dělat, a tedy na co se váš datový model může spolehnout.

Sales Cloud (dnes Agentforce Sales). Tito uživatelé mají plnou uživatelskou licenci Salesforce: standardní objekty CRM a jakoukoli standardní nebo vlastní aplikaci. To jsou zájemci, příležitosti a předpovědi navíc k účtům a kontaktům, a dokonce i případy: obchodník může vidět otevřené případy zákazníka před hovorem. Vytváření a spouštění kampaní vyžaduje ještě jeden díl, licenci funkce Marketing User.

Service Cloud (dnes Agentforce Service). Stejná uživatelská licence Salesforce, nastavená pro servis. Ve středu jsou případy, řešené v Service Console: licence funkce Service Cloud User otevírá Salesforce Console for Service. Tady žijí dohody o úrovni služeb (SLA), přes správu nároků a milníky, a tady přichází na řadu Knowledge, který většina edic kupuje jako doplněk.

Platform (Salesforce Platform). Pro lidi, kteří potřebují vaše vlastní aplikace, ne CRM. Dostanou účty, kontakty, sestavy, řídicí panely, dokumenty a každou vlastní aplikaci v orgu. Co nedostanou: předpovědi, zájemce, kampaně a příležitosti. Stojí méně, a právě proto na ní běží tolik velkých vlastních aplikací, a právě proto může nachytat váš datový model.

	Sales Cloud	Service Cloud	Platform
Uživatelská licence	Salesforce	Salesforce	Salesforce Platform
Určeno pro	Prodej	Podporu zákazníků	Vlastní aplikace
Účty, kontakty	Ano	Ano	Ano
Zájemci, příležitosti, předpovědi	Ano	Ano	Ne
Případy	Ano, kvůli přehledu o případech zákazníka	Ve středu, v Service Console	Ne
Dohody o úrovni služeb	Ne	Ano, nároky a milníky	Ne
Vlastní objekty a aplikace	Ano	Ano	Ano

Čtěte tabulku tak, jak to dělá architekt. Pokud je velká skupina uživatelů na Platform, každý návrh, který dává jejich práci na příležitost, je rozbitý dřív, než začne. Pokud vedení potřebuje čísla SLA, rozhoduje licence, na které je, o tom, jestli je uvidí. Tyto tři typy řídí chování.

Kliknutím zvětšíte

Když o objektu rozhodne licence

Příležitost je oběť, na kterou jsem narážel nejčastěji. Viděli jste to v tabulce: uživatelé Platform ji nedostanou (Standard User Licenses (otevře se v nové kartě)) a ani uživatelé Customer Community s ní pracovat nemohou. Požadavek tedy vypadá jako příležitost, někdo řekne „použijme Opportunity“, a pak se zeptám, kdo potřebuje přístup. Pokud je velká skupina na licencích Platform nebo Customer Community, licence už není detail nákupu. Je to architektonické omezení a obvykle tlačí návrh k vlastnímu objektu.

Funguje to i směrem nahoru. Ve třídě se ptám: generální ředitel chce hezké řídicí panely; licence Sales, nebo Service? Uživatel Sales vidí prodejní objekty, a dokonce i případy, takže pro prodejní panely a počty otevřených případů Sales stačí. Ve chvíli, kdy vedení chce KPI pro SLA (jak dlouho do porušení úrovně služeb u případu), ta data sedí v nárocích a milnících a správa nároků potřebuje Agentforce Service, dříve Service Cloud (Supported Editions for Service Features (otevře se v nové kartě)). Teď vedení zvyšujete licence. Poslouchejte obchodní požadavek a vězte, jaká licence leží pod daty, která potřebuje.

Stadion

Představuji si licence jako sedadla na stadionu. Všichni se dívají na stejný zápas. Když si koupím drahá sedadla uprostřed, vidím oba týmy zblízka. Když sedím nahoře v rohu na tribuně, sedadla nejsou polstrovaná a dívám se dalekohledem.

To jsou externí licence, pro lidi mimo firmu: zákazníky a partnery, kteří se přihlašují na web Experience Cloud. Chci, abyste znali tři.

Customer Community: tribuna nahoře. Postavená pro velké počty externích uživatelů, kteří potřebují případy a znalosti: zákazník, který kontroluje svůj případ podpory. Sedadla stojí zhruba polovinu a mohou jít obrovským počtům uživatelů. Co tam nahoře ztratíte? Sestavy, řídicí panely a tabulku sdílení: sdílení podle rolí, které dostávají vyšší úrovně. Funguje s osobními účty.

Customer Community Plus: zhruba v polovině cesty dolů. Salesforce ji popisuje jako licenci pro externí uživatele, kteří potřebují sestavy, řídicí panely a standardní sdílení: zákazník, který spravuje přístup jiných lidí nebo potřebuje vidět svá čísla.

Partner Community: ještě blíž, pro business-to-business, s přístupem k prodejním datům. Partneři pracují se zájemci a příležitostmi: registrují obchody a spouštějí s vámi kampaně. To je externí sedadlo, které dosáhne na prodejní objekty. Jeden háček: nelze ji používat s osobními účty (Experience Cloud User Licenses (otevře se v nové kartě)).

Kliknutím zvětšíte

Chybou je navrhovat, jako by všichni měli drahý lístek, a pak při implementaci zjistit, že většina vašich uživatelů se nedostane do sektoru, kam jste dali jejich data. Pak máte tři možnosti: koupit jiná sedadla, přesunout zážitek, nebo přenavrhnout model. Všechny tři jsou architektura.

Jak platí, mění návrh

Je tu další otázka, na kterou lidé zapomínají: jak se tito uživatelé budou přihlašovat? Externí licence mají dvě podoby. Podle členů (member-based): platíte za uživatele, což sedí na 500 partnerů, kteří se přihlašují každý den. Podle přihlášení (login-based): kupujete počet přihlášení za měsíc, což sedí na pět milionů zákazníků, kteří se přihlásí párkrát za rok. Víc přihlášení ve stejný den se pořád počítá jako jedno (Experience Cloud User Licenses (otevře se v nové kartě)).

Když tedy někdo řekne „stavíme zákaznický portál“, moje další otázka nezní, jaká šablona. Zní: kdo jsou ti zákazníci, kolik jich je, jak často přicházejí, jaká data potřebují a co s nimi smějí dělat?

Když licence tvaruje model

Někdy licence nejen vybere objekt; ohne celý model. Některé licence platformy omezují uživatele na jednu vlastní aplikaci s nejvýše deseti vlastními objekty (například Lightning Platform – One App; Standard User Licenses (otevře se v nové kartě)).

Na jednom raném projektu, pro velkou firmu v oblasti odborných služeb a stavebnictví, jsme museli postavit něco jako LinkedIn pro celou pracovní sílu: pracovní pozice, dovednosti, certifikace, jazyky a projekty všech, aby mohli najít stavitele mostů certifikovaného v dané zemi. Bez omezení bych postavil objekt uživatel–pozice, uživatel–dovednost, uživatel–certifikace, uživatel–jazyk a uživatel–projekt, plus referenční seznamy certifikací a projektů. S licencí na deset objektů a s pokynem nespotřebovat je všechny to nešlo. Stala se z toho tedy hra „poznej melodii“: s jak málo objekty to dokážu postavit? Odpověď byla dva. Jeden referenční objekt, s typem záznamu pro každý druh seznamu (pozice, dovednost, certifikace, jazyk, projekt), a jeden objekt atributů uživatele, s odpovídajícími typy záznamu, který na něj ukazoval.

Nebyl to optimální model. Sestavy nad ním byly utrpení a raději bych ho měl čistší. Ale to licence dovolila. Říkám jim objekty švýcarský nůž: mějte ten vzor v zadní kapse, a když vám limity nenechají místo, rozbijte sklo a sáhněte po oddělení typy záznamu. Jen vězte, co vyměňujete. Různá oprávnění podle typu záznamu vás mohou stejně donutit objekt rozdělit.

Uživateli už nejsou jen lidé

Jedna další licenční otázka se stala důležitou: co věci, které nejsou lidé? Integrace mají identity. Agenti mají identity. Salesforce teď má licenci Salesforce Integration pro integrace systém–systém: jen API, ne pro lidi, pět kusů zahrnutých v každém orgu edice Enterprise, Unlimited a Performance (Standard User Licenses (otevře se v nové kartě)). Neptejte se tedy jen, kteří uživatelé potřebují přístup. Ptejte se, které identity potřebují přístup: člověk, zákazník, partner, integrace, agent. A pak, co každá z nich potřebuje vidět a dělat.

Nad rámec zkoušky: co mění AI. Jak se agenti stávají dalším spotřebitelem a tvůrcem dat, volba objektu a licence už není jen o lidských obrazovkách. Vězte, pod jakou identitou agent běží, kam ta identita dosáhne a jestli model nedává data, která agent potřebuje, za objekt nebo oprávnění, které nemůže použít.

Steve Trucking: jeden snadný a jeden těžký

Steve Trucking spolupracuje s maloobchodními partnery. Co je maloobchodní partner? Firma. Snadné: účet. Nevytvořím Retail_Partner__c jen proto, že někdo použil slovo „partner“.

Teď příjemce, osoba, která přebírá ledničku. Kontakt? Osobní účet? Něco jiného? Milion nových příjemců ročně, kteří jsou zákazníky maloobchodních partnerů, ne našimi. Přesně u takové otázky nechci skočit k objektu dřív, než pochopím vztah, přístup a měřítko. Rozhodneme ji u kontrolního bodu části 1.

Co tady rozhoduje architekt

• Zda obchodní pojem čistě sedí na zamýšlený účel standardního objektu, nebo zda je jeho význam či váha jiná.
• Zda různé obchodní názvy jsou různé entity, nebo jen různé role téže entity.
• Zda se každý člověk, externí uživatel, integrace a agent, který data potřebuje, dostane k zvolenému objektu v rámci plánovaných licencí.
• Jak skupina uživatelů a způsob přihlašování (podle členů, nebo podle přihlášení) ovlivňují licenci a model.
• Kdy licenční limit ospravedlní méně než optimální model a co ta výměna stojí v sestavách a oprávněních.

Nejde o to, že standardní objekty jsou dobré a vlastní špatné. Jde o to, že volba má důsledky a někdy o ní vůbec nerozhoduje podstatné jméno, ale lidé, a stroje, kteří to potřebují používat.

K prozkoumání

• Salesforce Help, Standard User Licenses (otevře se v nové kartě), ověřeno 2026-10-17: uživatelé Platform nemají nárok na předpovědi, zájemce, kampaně a příležitosti; jedna vlastní aplikace s nejvýše 10 vlastními objekty; pět licencí Salesforce Integration v každém orgu edice Enterprise.
• Salesforce Help, Experience Cloud User Licenses (otevře se v nové kartě), ověřeno 2026-10-17: Partner Community nelze používat s osobními účty; Customer Community Plus pro sestavy, řídicí panely a standardní sdílení; víc přihlášení za den se počítá jako jedno.
• Salesforce Help, Supported Editions for Service Features (otevře se v nové kartě), ověřeno 2026-10-17: dohody o úrovni služeb (správa nároků) s Agentforce Service; Knowledge ve většině edic za příplatek.
• Salesforce Help, Available Feature Licenses (otevře se v nové kartě), ověřeno 2026-10-17: Service Cloud User, „Access the Salesforce Console for Service“ (přístup do Salesforce Console for Service); Marketing User pro vytváření a správu kampaní.