Standardowe modele danych

🌐 Dostępne także w 28 językach

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 2 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Platforma danych Salesforce: więcej niż baza danych · Dalej: Zbuduj własny: obiekty niestandardowe

Pytanie, na które odpowiada ten moduł: co Salesforce już za ciebie zamodelował i jak to jest złożone?

W module 1 powiedziałem ci: patrz na statek-matkę. Zanim coś wymyślisz, zobacz, jak robi to sam Salesforce. W tym module naprawdę się przyglądamy. Salesforce zamodelował już za ciebie sporą część biznesu w swoich obiektach standardowych, a dwa z tych modeli wykonują większość pracy w większości orgów, do których trafiam: model sprzedaży (Sales) i model obsługi (Service). Zanim zdecydujesz, czy coś zasługuje na obiekt niestandardowy, musisz wiedzieć, co już jest. O tym są dwa kolejne moduły.

Co sprawia, że obiekt jest standardowy

Obiekt standardowy jest dostępny od razu po instalacji. Zbudował go Salesforce, ma określone przeznaczenie i przychodzi z własnymi polami i relacjami. Możesz dodawać do niego pola, budować wokół niego automatyzację i zmieniać jego układy stron, ale nie możesz go przeprojektować: standardowe pola i relacje należą do Salesforce.

Spójrz na nazwy. Account, Contact, Case. Bez prefiksu, bez sufiksu. Tak Salesforce rezerwuje tę przestrzeń dla siebie. Wszystko, co budujemy, kończy się na __c, więc Salesforce może w każdej chwili dodać nowe obiekty standardowe i nigdy nie zderzyć się z niczym w twoim orgu. I robi to w każdym wydaniu.

Gdzieś po drodze ktoś zbudował obiekt produktu, który się nie sprawdził i trzeba go było zostawić. Dlatego nazwa API brzmi Product2. To mój pierwszy papierek lakmusowy, kiedy ktoś mówi mi, że zna Salesforce.

Model sprzedaży

Zacznij od lewej, od potencjalnego klienta (lead): kogoś, kto może zostać klientem. Lead tak naprawdę nie jest jeszcze częścią modelu. To poczekalnia. Kiedy go konwertujesz, Salesforce tworzy prawdziwe rekordy: konto, kontakt i, jeśli jest transakcja, szansę sprzedaży. Dlatego rysuję leada z boku.

Konto to firma. Jej kontakty to ludzie w niej. Szansa sprzedaży to transakcja z tym kontem. Na razie nic zaskakującego.

Potem robi się ciekawie. Co jest w transakcji? Każda pozycja to produkt szansy sprzedaży (Opportunity Product), a produkt szansy sprzedaży nie wskazuje bezpośrednio na produkt. Wskazuje na pozycję cennika (Price Book Entry): ten produkt, w tej cenie, w tym cenniku. Pozycja cennika leży między produktem (Product) a cennikiem (Price Book), więc ten sam produkt może mieć jedną cenę w standardowym cenniku, a inną w cenniku dla partnerów.

To dwie relacje, które stały się rzeczami, jedna po drugiej. Pamiętasz pozycję dostawy z rozdziału 2, między dostawą a produktem, i Sztuczkę psa między Psem a Sztuczką? Salesforce zrobił tu dokładnie to samo, i to dwa razy: produkt szansy sprzedaży między szansą sprzedaży a pozycją cennika oraz pozycję cennika między produktem a cennikiem. Kiedy potrafisz to odczytać, potrafisz odczytać większość standardowego modelu danych.

Click to enlarge

Oto ten łańcuch z bliska, z polami, które go spinają:

Click to enlarge

Jedna zasada, o którą ludzie się potykają: istnieje standardowy cennik, a pozycja cennika w każdym innym cenniku może po prostu korzystać z ceny standardowej produktu. Zanim załadujesz produkty szansy sprzedaży, ustal, z którego cennika ona korzysta.

Model obsługi

Teraz druga strona domu. To samo konto, te same kontakty. Kiedy coś pójdzie nie tak, klient otwiera zgłoszenie.

Zgłoszenie zwykle dotyczy czegoś, co klient ma, a Salesforce ma na to obiekt: zasób (Asset). W module 5 nazwę go obiektem standardowym, który ludzie przeoczają. To rzecz, którą ma klient, niezależnie od tego, czy kupił ją od ciebie, czy nie.

A do czego klient ma prawo? To jest uprawnienie do wsparcia (Entitlement): wsparcie, które przysługuje kontu, często powiązane z zasobem, produktem albo umową serwisową. Dodaj uprawnienie do zgłoszenia, a zgłoszenie wie, jaki poziom wsparcia powinno dostać.

Click to enlarge

Spójrz na linię, która biegnie od zgłoszenia z powrotem do niego samego. Każde zgłoszenie ma pole Zgłoszenie nadrzędne (Parent Case), które wskazuje na inne zgłoszenie. To lookup do samego siebie (self-lookup): relacja obiektu z samym sobą. Wiele osób gubi się, kiedy widzi to pierwszy raz, więc oto dwa powody, dla których go używam.

Pierwszy: duży problem, który rozpada się na mniejsze. Klient zgłasza, że cała instalacja nie działa. Otwieramy zgłoszenia podrzędne dla sieci, sprzętu i konfiguracji, każde obsługiwane osobno, a wszystkie rozwiązują się w górę: zgłoszenie nadrzędne nie jest zamknięte, dopóki one nie są.

Drugi: historia. Zgłoszenie zamknięto w zeszłym miesiącu, a teraz ten sam problem wrócił. Nowe zgłoszenie wskazuje na pierwotne, więc każdy, kto je otworzy, widzi, że to już się zdarzyło i co wtedy zrobiono.

Do lookupów do samego siebie wrócimy, kiedy w module 7 dojdziemy do relacji.

Zauważ, że konto i kontakt są w tym samym miejscu na obu diagramach. To te same rekordy. Handlowiec i agent obsługi patrzą na tego samego klienta, z różnych stron domu. To jeden z najmocniejszych argumentów za pozostaniem przy standardzie: te modele zbudowano po to, żeby się spotykały.

Pliki i załączniki

Nie wszystko na rekordzie jest polem. Umowy, zdjęcia, pliki PDF i arkusze to pliki i należą do Salesforce Files, a nie do starego modelu Attachments (załączników), który jest przestarzały. Jeśli dokument mieszka już w SharePoint Online, OneDrive, Google Drive albo Box, Files Connect pozwala użytkownikom dotrzeć do niego z Salesforce bez kopiowania go.

Pliki liczy się inaczej niż rekordy. Salesforce dzieli przestrzeń dyskową na dwie części: przestrzeń na pliki (file storage) trzyma załączniki, Files, Salesforce CRM Content, pliki z Chattera i tym podobne, a przestrzeń na dane (data storage) trzyma twoje rekordy. Przestrzeń na pliki rośnie szybko, kiedy każdy rekord dostaje zdjęcia albo skany, więc duże ilości obrazów, takich jak zdjęcia z aplikacji terenowej, często należą w ogóle poza Salesforce, a Salesforce trzyma tylko link. Moduł 4 do tego wraca.

Dwie kolumny czy dwieście

Przestrzeń na dane też liczy się inaczej niż w bazie danych. W zwykłej bazie danych tabela z dwiema kolumnami i milionem wierszy jest mała, a tabela ze stu kolumnami i milionem wierszy to słoń. Salesforce waży je tak samo: większość rekordów liczy się jako około 2 KB, bez względu na to, ile mają pól. Są wyjątki. Kampania liczy się więcej, wiadomość e-mail liczy się według rzeczywistego rozmiaru, a konto osoby liczy się jako około 4 KB, bo jest kontem i kontaktem.

Oto wskazówka. Za każdym razem, kiedy wchodzę do nowego orgu, jednym z pierwszych miejsc, które odwiedzam, jest Setup → Storage Usage (Konfiguracja → wykorzystanie przestrzeni). Proszę nawet klienta o zrzut ekranu podczas pierwszej rozmowy. Ten ekran nie kłamie. Mówi, które obiekty rosną, a które już są słoniami.

Konta osób: gdy klientem jest osoba

Model konta i kontaktu świetnie działa dla firmy i ludzi w niej. Ale co, jeśli twój klient nie jest firmą? Co, jeśli to osoba?

Do tego służy konto osoby: konto i kontakt połączone w jeden rekord, dla pojedynczych ludzi. Jego pola kontaktu przychodzą razem z nim, a te niestandardowe pojawiają się z własnym sufiksem, __pc. Każde konto osoby liczy się zarówno do przestrzeni kont, jak i kontaktów, bo pod spodem jest jednym i drugim.

Jedno ostrzeżenie, zanim je włączysz: po włączeniu kont osób nie da się ich wyłączyć. To Test Odwracalności z rozdziału 1 w najczystszej postaci. Moduł 5 przedstawia moje stanowisko w sprawie tego, kiedy są tego warte.

Co tu decyduje architekt

• Które części biznesu Salesforce już zamodelował, zanim zaprojektuje się cokolwiek nowego.
• Czy pojęcie trafia do modelu sprzedaży, do modelu obsługi czy do obu, ze świadomością, że dzielą konto i kontakt.
• Gdzie mieszkają dokumenty i obrazy: w Salesforce Files, w podłączonym systemie plików czy poza platformą, z linkiem.
• Ile dane będą kosztować w przestrzeni dyskowej, liczonej tak, jak liczy ją Salesforce: rekordy, nie kolumny.
• Czy klientem jest firma czy osoba, zanim włączy się coś, czego nie da się wyłączyć.

A kiedy Salesforce nie ma tego, czego potrzebujesz? Budujesz to sam. O tym dalej.

Do zgłębienia

• OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (po angielsku, sprawdzono 2026-10-12): „element listy produktów Product2 powiązanych z szansą sprzedaży”; pozycja cennika jest wymagana.
• PricebookEntry (opens in a new tab), Object Reference (po angielsku, sprawdzono 2026-10-12): „powiązanie między Pricebook2 a Product2”; pozycja może korzystać z ceny standardowej.
• Case (opens in a new tab), Object Reference (po angielsku, sprawdzono 2026-10-12): ParentId, „identyfikator zgłoszenia nadrzędnego w hierarchii. Etykieta to Parent Case”; lookup do Case.
• Entitlement (opens in a new tab), Object Reference (po angielsku, sprawdzono 2026-10-12): „wsparcie klienta, które przysługuje kontu lub kontaktowi”, możliwie oparte na zasobie, produkcie albo umowie serwisowej.
• Data and Storage Resources (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-12): co obejmuje przestrzeń na pliki, a co przestrzeń na dane.
• Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-12): „większość rekordów Salesforce zajmuje około 2 KB przestrzeni na dane”; konta osób około 4 KB.
• Enable Person Accounts (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-10-12): „po włączeniu kont osób nie można ich wyłączyć”.
• Files Connect FAQ (opens in a new tab), Pomoc Salesforce (po angielsku, sprawdzono 2026-09-25).