Wybierz właściwy obiekt

🌐 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ł 5 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Gdzie mieszkają te dane? · Dalej: Pola to też architektura

Pytanie, na które odpowiada ten moduł: jakim obiektem Salesforce powinno stać się to pojęcie biznesowe i na co pozwalają licencje?

Utworzenie obiektu niestandardowego to jedna z najłatwiejszych rzeczy w Salesforce. Właśnie dlatego uważam, że tworzymy ich za dużo.

Jesteś na sesji wymagań i ktoś mówi: „Musimy śledzić naszych dystrybutorów”. Nowy obiekt niestandardowy: Distributor. Gotowe. Tyle że chcę, żeby architekt najpierw zadał inne pytanie: czym jest dystrybutor? To firma. Salesforce ma już całkiem dobry sposób odwzorowania firmy. Nazywa się konto. To nie znaczy, że odpowiedzią zawsze jest konto. Ale jeśli mam wyjaśnić, dlaczego firma nie jest kontem, chcę lepszego powodu niż „biznes nazywa ich dystrybutorami”.

Tu model logiczny z rozdziału 2 spotyka się z platformą, a moje stanowisko wyjściowe jest proste: jeśli pojęcie biznesowe czysto pasuje do zamierzonego przeznaczenia obiektu standardowego, zacznij od niego.

Zacznij od znaczenia

Nawet gdy coś zasługuje na bycie obiektem, nie zasługuje automatycznie na bycie obiektem niestandardowym. Zapytaj, co ta rzecz naprawdę odwzorowuje. Firmę albo organizację dowolnej formy? Zacznij od konta. Osobę, która pracuje z tą organizacją? Kontakt. Coś, co klient posiada albo kupił? Zasób (Asset). Coś, co próbujesz sprzedać? Teraz do rozmowy należy szansa sprzedaży.

Dlatego najpierw spojrzeliśmy na statek-matkę, w module 2. Te modele nie pasują do każdego biznesu, ale nie powinniśmy ich ignorować tylko dlatego, że budowanie własnych wydaje się czystsze. Zanim klikniesz Nowy obiekt niestandardowy, zapytaj, jak Salesforce modeluje to pojęcie, co zbudowano wokół tego modelu i z czego zrezygnujesz, jeśli go zastąpisz.

Test czystego dopasowania

Mój test to jedno pytanie: czy to pojęcie biznesowe czysto pasuje do zamierzonego przeznaczenia obiektu standardowego? Jeśli tak, skłaniam się ku obiektowi standardowemu.

Dystrybutor to firma, z którą mamy relację, więc konto pasuje czysto. Nie przeszkadza mi, że użytkownicy nazywają jedną firmę dystrybutorem, inną dostawcą, inną partnerem detalicznym, a jeszcze inną klientem. To role biznesowe i nie potrzebują czterech fizycznych obiektów. Różne nazwy biznesowe nie oznaczają automatycznie różnych struktur danych. Różnicę może nieść typ, typ rekordu albo relacja.

Test działa też w drugą stronę. W rozdziale 1 zostawiłem cię z pytaniem: firma klienta ma wiele miejsc dostaw. Czy każde miejsce powinno być kontem, czy obiektem niestandardowym?

Konto daje ci dużo. Dostajesz pola adresowe i wszystko, co już oczekuje adresu konta: raporty, mapy, integracje. Ale dostajesz też narzut: mnóstwo pól, udostępnianie, hierarchię, własność, wszystko, co wisi na koncie, a większość z tego nie ma znaczenia dla osobnego adresu. Nosiłbyś mnóstwo ciężkich rzeczy, których nie użyjesz, tylko dla alternatywnego adresu.

Obiekt niestandardowy, podrzędny wobec konta, może być lekki: tylko pola adresowe, miejsce, do którego dostarczamy, z własnym cyklem życia, którym mogę sterować niezależnie.

To więc kwestia równowagi: ciężar, który bierzesz na siebie, kontra wartość, którą dostajesz. Jeśli potrzebuję tylko adresu z własnym cyklem życia, tu idę w obiekt niestandardowy.

Tak samo z podproblemami zgłoszenia. Jeśli każdy podproblem naprawdę jest zgłoszeniem, obsługiwanym przez agenta, z własnym statusem i poziomem usług, zagnieżdżaj je przez zgłoszenie nadrzędne (Parent Case) z modułu 2. Ale jeśli to tylko pozycja na liście kontrolnej, której nikt nie obsługuje jak zgłoszenia, pełne zgłoszenie niesie mnóstwo rzeczy, których nigdy nie użyje, a prosty niestandardowy rekord podrzędny może ważyć mniej. Nie dlatego, że niestandardowe jest czystsze. Dlatego, że znaczenie jest inne albo ciężar jest niewłaściwy.

Obiekty standardowe przychodzą z bagażem

Wybierając obiekt standardowy, wybierasz więcej niż jego pola. Wybierasz coś, co produkty Salesforce już rozumieją: raportowanie, automatyzację, wbudowane relacje, funkcje produktów, pakiety z AppExchange i cokolwiek Salesforce zbuduje następnie. To może mieć ogromną wartość.

Obiekty standardowe mają też swoje zdanie: istniejące zachowanie, relacje, kwestie bezpieczeństwa, czasem wymagania licencyjne i funkcje, których nie potrzebujesz. Moja zasada nie brzmi więc „zawsze używaj obiektów standardowych”. Nie mam zasad typu „zawsze”. Mam skłonność: używaj obiektu standardowego, gdy znaczenie pasuje czysto, a zachowanie platformy wokół niego pomaga projektowi, a nie z nim walczy. Jeśli przez pięć lat zmuszam szansę sprzedaży, żeby zachowywała się jak coś, co nie jest szansą sprzedaży, niczego nie zyskałem, zostając przy standardzie. Po prostu zawarłem zły kompromis w drugą stronę.

Zasób to dobry przykład

Zasób (Asset) to jeden z obiektów standardowych, które ludzie przeoczają. Najprościej jak potrafię: to rzecz, którą ma klient. Może kupił ją od nas, może nie. Nadal obchodzi mnie produkt konkurencji stojący u mojego klienta, bo go serwisuję, próbuję go zastąpić albo muszę zrozumieć bazę zainstalowanych urządzeń. Jeśli utworzę Customer_Product__c, nie patrząc najpierw na zasób, pominąłem pytanie architektoniczne. Zasób nie wygrywa automatycznie, ale zasługuje na ocenę.

Konta osób: kiedy osoba jest kontem?

W module 2 poznaliśmy konta osób: konto i kontakt w jednym rekordzie, dla klientów, którzy są osobami prywatnymi. Teraz decyzja.

Moje stanowisko: w B2C trudno się bez nich obejść. Z kontami i kontaktami przychodzi od razu tak wiele, że koszt i narzut są tego warte. A koszt jest: mniej więcej dwa razy więcej miejsca niż konto firmowe, przełącznik, którego nie da się wyłączyć, i niektóre licencje zewnętrzne nie mogą z nich korzystać. Partner Community nie działa z kontami osób (Experience Cloud User Licenses (opens in a new tab), po angielsku). Pytanie nie brzmi więc „czy mamy ludzi w bazie danych?”. Każdy org ma ludzi. Brzmi: „czy w tym biznesie osoba naprawdę jest kontem?” To, że kontakt jest osobą, nie robi z niego konta osoby. Robi to relacja biznesowa.

Click to enlarge

Teraz wszystko skomplikuję: licencje

Dotąd: znajdź pojęcie, szukaj najczystszego dopasowania standardowego, idź w niestandardowe, gdy znaczenie nie pasuje. Teraz pytanie uzupełniające architekta: kto musi z tego korzystać? Możesz zaprojektować piękny model, a potem odkryć, że połowa ludzi, którzy potrzebują danych, nie ma licencji na wybrane obiekty. Licencje są częścią modelu danych.

Trzy licencje wewnętrzne

Zacznij od własnych ludzi. Wewnątrz firmy są trzy typy licencji, które każdy architekt powinien znać na wyrywki, bo decydują o tym, co każdy użytkownik może zobaczyć i zrobić, a więc na czym twój model danych może polegać.

Sales Cloud (dziś Agentforce Sales). Ci użytkownicy mają pełną licencję użytkownika Salesforce: standardowe obiekty CRM i dowolną aplikację standardową lub niestandardową. To potencjalni klienci, szanse sprzedaży i prognozy oprócz kont i kontaktów, a nawet zgłoszenia: handlowiec może przed rozmową zobaczyć otwarte zgłoszenia klienta. Tworzenie i prowadzenie kampanii wymaga jeszcze jednego elementu: licencji funkcji Marketing User.

Service Cloud (dziś Agentforce Service). Ta sama licencja użytkownika Salesforce, skonfigurowana do obsługi. W centrum są zgłoszenia, obsługiwane w Service Console: to licencja funkcji Service Cloud User otwiera konsolę Salesforce dla obsługi. Tu żyją umowy o poziomie usług (SLA), przez zarządzanie uprawnieniami do obsługi i kamienie milowe, i tu wchodzi Knowledge, którą większość edycji kupuje jako dodatek.

Platform (Salesforce Platform). Dla ludzi, którzy potrzebują twoich niestandardowych aplikacji, a nie CRM. Dostają konta, kontakty, raporty, pulpity, dokumenty i każdą niestandardową aplikację w orgu. Czego nie dostają: prognoz, potencjalnych klientów, kampanii i szans sprzedaży. Kosztuje mniej, i właśnie dlatego tyle dużych aplikacji niestandardowych na niej działa, i właśnie dlatego potrafi zaskoczyć twój model danych.

	Sales Cloud	Service Cloud	Platform
Licencja użytkownika	Salesforce	Salesforce	Salesforce Platform
Przeznaczenie	Sprzedaż	Obsługa klientów	Aplikacje niestandardowe
Konta, kontakty	Tak	Tak	Tak
Potencjalni klienci, szanse sprzedaży, prognozy	Tak	Tak	Nie
Zgłoszenia	Tak, by widzieć zgłoszenia klienta	W centrum, w Service Console	Nie
Umowy o poziomie usług (SLA)	Nie	Tak, uprawnienia do obsługi i kamienie milowe	Nie
Obiekty i aplikacje niestandardowe	Tak	Tak	Tak

Czytaj tę tabelę jak architekt. Jeśli duża grupa użytkowników ma licencję Platform, każdy projekt, który umieszcza ich pracę na szansie sprzedaży, jest zepsuty, zanim się zacznie. Jeśli członkowie zarządu potrzebują liczb SLA, to ich licencja decyduje, czy je zobaczą. Te trzy typy sterują zachowaniem.

Click to enlarge

Gdy licencja decyduje o obiekcie

Szansa sprzedaży to ofiara, na którą trafiam najczęściej. Widzisz to w tabeli: użytkownicy Platform jej nie dostają (Standard User Licenses (opens in a new tab), po angielsku), a użytkownicy Customer Community też nie mogą z nią pracować. Wymaganie wygląda więc jak szansa sprzedaży, ktoś mówi: „użyjmy szansy sprzedaży”, a wtedy ja pytam, kto potrzebuje dostępu. Jeśli duża grupa ma licencje Platform albo Customer Community, licencja przestaje być szczegółem zakupowym. To ograniczenie architektoniczne i zwykle pcha projekt w stronę obiektu niestandardowego.

Działa to też w górę. Na zajęciach pytam: prezes chce ładnych pulpitów; licencja Sales czy Service? Użytkownik Sales widzi obiekty sprzedażowe, a nawet zgłoszenia, więc do pulpitów sprzedażowych i liczby otwartych zgłoszeń Sales wystarczy. Ale w chwili, gdy członek zarządu chce wskaźników SLA (ile czasu zostało, zanim zgłoszenie przekroczy poziom usług), te dane siedzą w uprawnieniach do obsługi i kamieniach milowych (entitlements, milestones), a zarządzanie uprawnieniami do obsługi wymaga Agentforce Service, dawniej Service Cloud (Supported Editions for Service Features (opens in a new tab), po angielsku). Teraz podnosisz licencje członków zarządu. Słuchaj wymagania biznesowego i wiedz, jaka licencja leży pod danymi, których ono potrzebuje.

Stadion

Myślę o licencjach jak o miejscach na stadionie. Wszyscy oglądają ten sam mecz. Jeśli kupię drogie miejsca pośrodku, widzę obie drużyny z bliska. Jeśli siedzę w rogu na górnej trybunie, siedzenia nie są wyściełane, a mecz oglądam przez lornetkę.

Tak wyglądają licencje zewnętrzne, dla ludzi spoza firmy: klientów i partnerów logujących się do witryny Experience Cloud. Są trzy, które chcę, żebyś znał.

Customer Community: górna trybuna. Stworzona dla dużej liczby użytkowników zewnętrznych, którzy potrzebują zgłoszeń i bazy wiedzy: klient sprawdzający swoje zgłoszenie do pomocy technicznej. Miejsca kosztują mniej więcej połowę i można je dać ogromnej liczbie użytkowników. Co tam tracisz? Raporty, pulpity i tabelę udostępniania: udostępnianie oparte na rolach, które dostają wyższe poziomy. Działa za to z kontami osób.

Customer Community Plus: mniej więcej w połowie wysokości. Salesforce opisuje ją jako licencję dla użytkowników zewnętrznych, którzy potrzebują raportów, pulpitów i standardowego udostępniania: klient, który zarządza dostępem innych osób albo musi widzieć swoje liczby.

Partner Community: jeszcze bliżej, dla relacji business-to-business, z dostępem do danych sprzedażowych. Partnerzy pracują z potencjalnymi klientami i szansami sprzedaży: rejestrują transakcje i prowadzą z tobą kampanie. To miejsce zewnętrzne, które sięga obiektów sprzedażowych. Jeden haczyk: nie działa z kontami osób (Experience Cloud User Licenses (opens in a new tab), po angielsku).

Click to enlarge

Błędem jest projektowanie tak, jakby wszyscy mieli drogi bilet, a potem odkrycie przy wdrożeniu, że większość użytkowników nie może wejść do sektora, w którym umieszczono ich dane. Wtedy masz trzy wyjścia: kupić inne miejsca, przenieść doświadczenie albo przeprojektować model. Wszystkie trzy to architektura.

Sposób płacenia zmienia projekt

Jest jeszcze jedno pytanie, o którym ludzie zapominają: jak ci użytkownicy będą się logować? Licencje zewnętrzne mają dwa kształty. Członkowskie (member-based): płacisz za użytkownika, co pasuje do 500 partnerów logujących się codziennie. Logowaniowe (login-based): kupujesz liczbę logowań miesięcznie, co pasuje do pięciu milionów klientów logujących się kilka razy w roku. Kilka logowań tego samego dnia nadal liczy się jako jedno (Experience Cloud User Licenses (opens in a new tab), po angielsku).

Kiedy więc ktoś mówi „budujemy portal klienta”, moje następne pytanie nie dotyczy szablonu. Brzmi: kim są klienci, ilu ich jest, jak często przychodzą, jakich danych potrzebują i co wolno im z nimi robić?

Gdy licencja kształtuje model

Czasem licencja nie tylko wybiera obiekt; wygina cały model. Niektóre licencje platformowe ograniczają użytkowników do jednej aplikacji niestandardowej z maksymalnie dziesięcioma obiektami niestandardowymi (na przykład Lightning Platform – One App; Standard User Licenses (opens in a new tab), po angielsku).

Przy jednym z wczesnych projektów, dla dużej firmy usług profesjonalnych i budowlanych, musieliśmy zbudować coś w rodzaju LinkedIn dla całej kadry: stanowiska, umiejętności, certyfikaty, języki i projekty każdego pracownika, żeby dało się znaleźć budowniczego mostów z certyfikatem w danym kraju. Bez limitu zbudowałbym obiekty użytkownik-stanowisko, użytkownik-umiejętność, użytkownik-certyfikat, użytkownik-język i użytkownik-projekt plus listy referencyjne certyfikatów i projektów. Przy licencji na dziesięć obiektów, z poleceniem, żeby nie zużyć ich wszystkich, nie było to możliwe. Zrobiła się z tego zgadywanka: z jak niewielu obiektów da się to zbudować? Odpowiedź brzmiała: z dwóch. Jeden obiekt referencyjny, z typem rekordu dla każdego rodzaju listy (stanowisko, umiejętność, certyfikat, język, projekt), i jeden obiekt atrybutu użytkownika, z pasującymi typami rekordów, wskazujący na niego.

To nie był optymalny model. Raportowanie na nim było męczarnią i wolałbym coś czystszego. Ale tylko na tyle pozwalała licencja. Nazywam je obiektami-scyzorykami: trzymaj ten wzorzec w zanadrzu, a gdy limity nie zostawiają miejsca, zbij szybkę i sięgnij po rozdzielenie typami rekordów. Tylko wiedz, z czego rezygnujesz. Różne uprawnienia dla różnych typów rekordów mogą i tak zmusić cię do podzielenia obiektu.

Ludzie to już nie jedyni użytkownicy

Jeszcze jedno pytanie licencyjne stało się ważne: co z tym, co nie jest ludźmi? Integracje mają tożsamości. Agenci mają tożsamości. Salesforce ma teraz licencję Salesforce Integration dla integracji system-system: tylko API, nie dla ludzi, z pięcioma licencjami w każdym orgu w edycjach Enterprise, Unlimited i Performance (Standard User Licenses (opens in a new tab), po angielsku). Nie pytaj więc tylko, którzy użytkownicy potrzebują dostępu. Pytaj, które tożsamości potrzebują dostępu: osoba, klient, partner, integracja, agent. A potem, co każda z nich musi widzieć i robić.

Poza egzaminem: co zmienia AI. Gdy agenci stają się kolejnym odbiorcą i twórcą danych, wybór obiektu i licencje nie dotyczą już tylko ekranów dla ludzi. Wiedz, jako jaka tożsamość działa agent, do czego ta tożsamość może dotrzeć i czy model nie umieszcza potrzebnych mu danych za obiektem albo uprawnieniem, z którego nie może korzystać.

Steve Trucking: jeden łatwy i jeden trudny

Steve Trucking współpracuje z partnerami detalicznymi. Czym jest partner detaliczny? Firmą. Łatwe: konto. Nie tworzę Retail_Partner__c tylko dlatego, że ktoś użył słowa „partner”.

Teraz odbiorca, osoba, która odbiera lodówkę. Kontakt? Konto osoby? Coś innego? Milion nowych odbiorców rocznie, którzy są klientami partnerów detalicznych, a nie naszymi. To dokładnie ten rodzaj pytania, przy którym nie chcę skakać do obiektu, zanim zrozumiem relację, dostęp i skalę. Zdecydujemy o tym w punkcie kontrolnym części 1.

Co tu decyduje architekt

• Czy pojęcie biznesowe czysto pasuje do zamierzonego przeznaczenia obiektu standardowego, czy jego znaczenie albo ciężar są inne.
• Czy różne etykiety biznesowe to różne encje, czy tylko różne role tej samej.
• Czy każda osoba, użytkownik zewnętrzny, integracja i agent, którzy potrzebują danych, mogą dotrzeć do wybranego obiektu w ramach planowanych licencji.
• Jak liczebność grupy i sposób logowania (członkowski czy logowaniowy) kształtują licencję i model.
• Kiedy limit licencyjny uzasadnia model mniej niż optymalny i ile ten kompromis kosztuje w raportowaniu i uprawnieniach.

Nie chodzi o to, że obiekty standardowe są dobre, a niestandardowe złe. Chodzi o to, że wybór ma konsekwencje, a czasem nie decyduje o nim wcale rzeczownik, tylko ludzie i maszyny, które muszą z niego korzystać.

Do zgłębienia

• Pomoc Salesforce, Standard User Licenses (opens in a new tab) (po angielsku), sprawdzono 2026-10-02, ponownie 2026-10-12: użytkownicy Platform nie mają prawa do prognoz, potencjalnych klientów, kampanii i szans sprzedaży; jedna aplikacja niestandardowa z maksymalnie 10 obiektami niestandardowymi; pięć licencji Salesforce Integration w każdym orgu Enterprise Edition.
• Pomoc Salesforce, Experience Cloud User Licenses (opens in a new tab) (po angielsku), sprawdzono 2026-10-02, ponownie 2026-10-12: Partner Community nie działa z kontami osób; Customer Community Plus do raportów, pulpitów i standardowego udostępniania; kilka logowań w ciągu dnia liczy się jako jedno.
• Pomoc Salesforce, Supported Editions for Service Features (opens in a new tab) (po angielsku), sprawdzono 2026-10-02, ponownie 2026-10-12: umowy o poziomie usług (zarządzanie uprawnieniami do obsługi) w Agentforce Service; Knowledge za dodatkową opłatą w większości edycji.
• Pomoc Salesforce, Available Feature Licenses (opens in a new tab) (po angielsku), sprawdzono 2026-10-12: Service Cloud User, „Access the Salesforce Console for Service”; Marketing User do tworzenia kampanii i zarządzania nimi.