Zaprojektuj fizyczny model w Salesforce

🌐 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ł 10 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Spójność danych · Dalej: przewodnik do nauki do rozdziału, potem następny rozdział, Zrozumieć dane przedsiębiorstwa

Pytanie, na które odpowiada ten moduł: jak zamienić nasz model logiczny w architekturę Salesforce?

Cały ten rozdział to jeden długi argument, że platforma ma kształt: obiekty standardowe i niestandardowe, miejsca, w których mogą mieszkać dane, typy pól, relacje, własność, licencje, reguły spójności, przestrzeń i skala. Każda z tych rzeczy może zmienić sposób, w jaki buduje się model logiczny z rozdziału 2. Teraz złóżmy to razem na jednym wycinku Steve Trucking.

Jeden wycinek, nie cała firma. Błąd, który widzę u architektów, to próba rozwiązania całego przedsiębiorstwa na jednym diagramie. Chcę czegoś, o czym da się rozumować: partner detaliczny wysyła manifest, Steve Trucking dostarcza to, co w nim jest, a my zachowujemy to, czego potrzebujemy o każdej dostawie. Potem podejmujemy decyzje fizyczne po kolei. Pełny projekt to punkt kontrolny części 1.

Zacznij od tego, co już wiemy

Rozdział 2 wykonał pracę konceptualną: partner detaliczny, odbiorca, manifest, dostawa, pozycja dostawy, rodzaj przystanku, ekipa, ciężarówka, centrum dystrybucyjne, zdjęcia. Nazwaliśmy relacje i zapytaliśmy, co znaczą. Nie będę tego powtarzał. Teraz pytanie brzmi, jak te pojęcia żyją w Salesforce. Jeden fakt z opisu ma znaczenie od razu: Steve Trucking już używa Field Service do wizyt, ekip i aplikacji mobilnej.

Partner detaliczny: nie wymyślaj konta

Partner detaliczny to firma, dla której pracuje Steve Trucking. Salesforce ma już obiekt zaprojektowany dla firm: konto. Czyste dopasowanie. Żadnego Retail_Partner__c tylko dlatego, że biznes mówi „partner”. To konto z typem rekordu Retail Partner, żeby odróżnić je od innych organizacji, a razem z nim przychodzą umowy, zgłoszenia, kontakty dla kierowników CD i dostęp do portalu dla tych kontaktów. Łatwa decyzja. Nie wszystkie takie są.

Numer zamówienia partnera to nie nasza tożsamość

Każdy partner detaliczny wysyła własne numery. Zamówienie jednego partnera wygląda jak 8843119, innego jak A-984732. Te numery mają znaczenie, ale czyje są? Partnera. Salesforce ma własny identyfikator rekordu, a partner ma numer, którego używa, rozmawiając z nami. Oba mogą istnieć; to „jedna rzecz, kilka identyfikatorów” z rozdziału 2.

Numer partnera staje się więc External ID, którego integracja używa do dopasowywania aktualizacji. A ponieważ dwóch partnerów może użyć tego samego numeru, tożsamością jest partner plus numer, a nie sam numer. Nie rób z numeru partnera uniwersalnej tożsamości dostawy tylko dlatego, że przyszedł pierwszy, i nie każ integracji przeszukiwać pola tekstowego za każdym razem, gdy musi znaleźć rekord.

Dostawa: patrz na statek-matkę

Tu kusi, żeby utworzyć Delivery__c. Biznes powiedział „dostawa”, więc potrzebujemy obiektu Delivery. Właśnie tego nie chcę, żeby robić jako pierwszego. Patrz na statek-matkę, tak jak w module 2. Co Salesforce już ma dla pracy wykonywanej w określonym miejscu, z cyklem życia, pozycjami, planowaniem i ekipą w terenie? Work Order (zlecenie pracy) z Field Service: Salesforce opisuje go jako pracę serwisu terenowego do wykonania dla klienta (WorkOrder (opens in a new tab), po angielsku). Zaplanowana wizyta i jej okno czasowe to Service Appointment (wizyta serwisowa), i to ją planuje dyspozycja i pokazuje aplikacja ekipy.

A więc dostawa → Work Order. Nie dlatego, że słowa pasują; nie pasują. Dlatego, że zachowanie pasuje do możliwości platformy, za które już płacimy i z których zamierzamy korzystać. Obiekt standardowy nie musi mieć tego samego słownictwa co biznes. Musi poprawnie odwzorowywać pojęcie.

Click to enlarge

Krok 1 z 4: statek-matka. Każda karta to pojęcie biznesowe, a pod nim jego obiekt Salesforce.

Ale obiekty standardowe przychodzą z bagażem

Druga połowa: Work Order nie jest za darmo. Przynosi licencje Field Service, własne relacje, zachowanie bezpieczeństwa, pola wymagane, automatyzację i cykl życia, a inne części platformy oczekują, że będzie zachowywał się w określony sposób. Wybieramy go, bo dopasowanie jest czyste i korzystamy z tego, co wokół niego zbudowano. Gdyby Steve Trucking nie chciał nic z Field Service, a model walczył z procesem na każdym kroku, przemyślałbym to. Architekturą jest dopasowanie, a nie etykieta.

Pozycje dostawy: idź za modelem

Skoro dostawa to Work Order, przyjrzyj się reszcie tego modelu, zanim cokolwiek wymyślisz. Work Order Line Item to podzadanie zlecenia pracy (WorkOrderLineItem (opens in a new tab), po angielsku): lodówka, instalacja, wywóz. A więc pozycja dostawy → Work Order Line Item. Zwróć uwagę, że pierwsza decyzja ukształtowała drugą. Nie wybieramy obiektu dla każdej encji osobno. Przyjmij model i zrozum jego resztę, zanim zbudujesz wokół niego niestandardowe struktury.

Jaki to rodzaj przystanku?

W Steve Trucking przystanek to tylko dostawa, dostawa z instalacją albo dostawa z wywozem, a każdy rodzaj ma własny czas trwania, umiejętności ekipy i listę kontrolną instalacji. W rozdziale 2 uznaliśmy, że to encja, a nie etykieta. Field Service już ją ma: Work Type (typ pracy), szablon rodzaju pracy, który można stosować do zleceń pracy i ich pozycji (WorkType (opens in a new tab), po angielsku). A więc rodzaj przystanku → Work Type. Znowu nie dlatego, że istnieje coś o nazwie Work Type, ale dlatego, że pojęcie i zachowanie się zgadzają.

Click to enlarge

Krok 2 z 4: idź za modelem. Pozycje i Work Type przychodzą razem z Work Order.

Manifest: teraz chcę obiektu niestandardowego

Czy istnieje obiekt standardowy dla „listy partnera na wtorek w CD w Phoenix”? Właściwie nie, a ja nie będę wciskał tego do niezwiązanego obiektu tylko po to, żeby móc powiedzieć, że zostaliśmy przy standardzie. Manifest → Manifest__c. To jednostka odbioru: skąd przyszedł (plik, partia z API), kiedy, jego status i sumy, a gdy partner wysyła go ponownie w dniu dostawy, co jest porównywane. Każda pozycja manifestu staje się Work Order powiązanym z nim z powrotem.

Niestandardowe to nie porażka. To jest to, co daje nam platforma, gdy pojęcie nie ma czystego standardowego domu. Błędem nie jest utworzenie obiektu niestandardowego; błędem jest utworzenie go bez sprawdzenia, czy platforma już ma to pojęcie.

Click to enlarge

Krok 3 z 4: jedyny obiekt niestandardowy, tam, gdzie nie pasuje żaden obiekt standardowy.

Zdjęcia: to, że Salesforce może je przechowywać, nie znaczy, że powinien

„Potrzebujemy zdjęć z dostaw w Salesforce”. Co znaczy „w Salesforce”? Użytkownicy muszą je widzieć z poziomu Salesforce, tak. Czy to znaczy, że pliki graficzne muszą mieszkać w przestrzeni core? Niekoniecznie. Policz zera: około czterech zdjęć na dostawę, więcej przy instalacjach, przy milionie dostaw rocznie to cztery do pięciu milionów zdjęć rocznie, a dostaw przybywa o 30% rocznie.

Moje stanowisko wyjściowe: nie zamieniaj orgu core w gigantyczne repozytorium zdjęć tylko dlatego, że użytkownicy potrzebują dostępu do zdjęć. Pliki należą do magazynu zbudowanego na taki wolumen, poza core, a Salesforce trzyma to, czego potrzebuje, żeby je znaleźć i pokazać: odwołanie, licznik albo mały rekord indeksu na zdjęcie oraz flagę, że wymagane zdjęcia z instalacji są kompletne. Dostęp do danych i miejsce, w którym fizycznie mieszkają, to dwa różne pytania. To powrót modułu 4.

Pola: pokaż znaczenie

Work Order potrzebuje pól: numeru partnera, okna dostawy, rzeczywistego czasu dostawy, statusu, uwag w rodzaju „kod do bramy” czy „pies na podwórku”. Nie zamienię tego w katalog pól; zrobił to moduł 6. Zadaj każdemu te same pytania: co znaczy, kto jest właścicielem, czy się zmienia, czy to identyfikator, kontrolowane słownictwo, przechowywane czy wyliczane, wrażliwe. Numer partnera to External ID, więc jego unikalność jest częścią kontraktu integracyjnego, a nie tylko polem wyboru. Rzeczywisty czas dostawy to moment, więc Data/godzina. Status steruje zachowaniem, więc kontrolowana lista, nigdy dowolny tekst. A uwagi do dostawy o czyimś domu to dane osobowe, więc zostają sklasyfikowane. Każde pole prowadzi z powrotem do znaczenia.

Relacje: nie łącz tylko prostokątów

Konto do Work Order, Work Order do jego pozycji, manifest do Work Order, Work Type opisujący przystanek. Potem pytania z modułu 7 dla każdej linii: czy rekord podrzędny może istnieć sam, kto jest jego właścicielem, czy dostęp jest dziedziczony, czy może się przenosić, co się dzieje przy usuwaniu, ile rekordów podrzędnych może się nagromadzić? Każdy Work Order pod garstką kont partnerów detalicznych oznacza setki tysięcy rekordów podrzędnych na rodzica: pytanie o nierównomierny rozkład, na które odpowiemy w części 2. A w przypadku standardowych relacji Field Service sprawdź, jak Salesforce już je zbudował, zamiast zakładać, że pasują do tego, co sami byśmy zaprojektowali. Przyjmując standardowy model, przyjmujesz decyzje, które Salesforce w nim podjął. Zrozum je, zanim zaczniesz budować na wierzchu.

Własność i odbiorca: nie pozwól, żeby zdecydowały ustawienia domyślne

Dwie decyzje, które ustawienie domyślne chętnie podjęłoby za nas.

Kto jest właścicielem dostawy? Odpowiedzieliśmy na to w module 8 i przenosi się to wprost na Work Order: własność nie decyduje tu o niczyim dostępie, więc właścicielem tworzonych przez siebie Work Orders jest użytkownik integracyjny. Dyspozytorzy widzą te ze swojego centrum dystrybucyjnego, ekipy te ze swoich tras, a każdy partner detaliczny swoje przez portal, wszystko przez udostępnianie, nie przez własność. Użytkownik integracyjny nie ma roli i pozostaje poza grupami publicznymi, których używają nasze reguły udostępniania, bo przy 3300 dziennie przekracza 10 000 rekordów w trzy dni. I zapisujemy, co się stanie, jeśli ten użytkownik zostanie kiedyś zastąpiony.

Czym jest odbiorca? Kontaktem? Kontem osoby? Czymś przechowywanym tylko na dostawie? To zależy od tego, czy Steve Trucking w ogóle ma relację z tymi ludźmi (to klienci partnerów detalicznych), czy jeden partner może kiedykolwiek zobaczyć odbiorców innego, jak długo wolno przechowywać ich dane osobowe, i od skali: około miliona nowych odbiorców rocznie. Nie mamy jeszcze tego wszystkiego i to w porządku. Czasem właściwa odpowiedź brzmi: jeszcze nie wiemy wystarczająco dużo. Zapisz pytanie i zdobądź informacje; nie zakopuj niepewności w obiekcie niestandardowym. Odpowiemy na nie w punkcie kontrolnym części 1, gdy rozdziały 4–6 dadzą nam obraz przedsiębiorstwa i danych podstawowych.

Spójność: chroń model na właściwej warstwie

Obowiązuje drabina z modułu 9: numer partnera to External ID, unikalny, więc ponownie wysłany manifest wykonuje upsert zamiast duplikować; status to ograniczona lista; rzeczywisty czas dostawy jest wymagany dopiero wtedy, gdy status mówi Dostarczona; przystanku z instalacją nie można zamknąć bez listy kontrolnej i zdjęć. Nie jeden gigantyczny Flow. Każda reguła na własnym szczeblu.

Gdzie mieszka każdy element

Jeszcze jedno przejście przez wycinek, z pytaniem z modułu 4: gdzie mieszka każdy element danych? W moich slajdach z zajęć to jeden slajd, model logiczny kontra fizyczny: encje logiczne z rozdziału 2 i miejsce, w którym każda fizycznie ląduje: w core, jako sObject (__c, jeśli jest niestandardowy) albo big object (__b), albo poza core, jako obiekt zewnętrzny (__x) albo dane, które w ogóle nie trafiają do Salesforce.

• W core, codzienna praca: konto, Work Orders i ich pozycje, Service Appointments, Work Types, Manifest__c.
• W core, zarchiwizowane: dostawy starsze niż trzy lata przechodzą do historii dostaw (Delivery History), czyli big object, nadal dostępne na potrzeby reklamacji, w szopie za domem.
• Wskazywane: szczegóły zamówień partnera detalicznego zostają w systemie partnera; numer partnera trzymamy jako External ID, a do reszty sięgamy przez obiekt zewnętrzny albo integrację, gdy ktoś jej potrzebuje.
• Poza core: zdjęcia, w magazynie zbudowanym na miliony obrazów, z linkiem z Work Order.

To jest model fizyczny: nie tylko który obiekt, ale który dom.

Teraz spójrz na cały wycinek

• Partner detaliczny → konto z typem rekordu Retail Partner; kierownicy CD jako kontakty.
• Dostawa → Work Order z Field Service, planowany przez Service Appointment.
• Pozycja dostawy → Work Order Line Item.
• Rodzaj przystanku → Work Type.
• Manifest → niestandardowy Manifest__c.
• Numer partnera → External ID na Work Order, unikalny w obrębie partnera.
• Zdjęcia → przechowywane poza core; Salesforce trzyma odwołanie i flagę kompletności.
• Historia dostaw → archiwizowana do big object po trzech latach.
• Własność → użytkownik integracyjny, z dostępem przez udostępnianie (moduł 8).
• Odbiorca → otwarte, na punkt kontrolny części 1.

Click to enlarge

Krok 4 z 4: cały wycinek, w core, zarchiwizowany i poza core. Każda linia to lookup: Salesforce zbudował Field Service na lookupach, a my przyjmujemy jego decyzje razem z nim.

Diagram to nie architektura

Mogę ci dać ten diagram, ale to nie wystarczy. Architekturą jest rozumowanie za nim. Dlaczego konto? Firma, czyste dopasowanie. Dlaczego Work Order, a nie Delivery__c? Dostawa zachowuje się jak praca w terenie, a Field Service już jest na miejscu. Dlaczego niestandardowy manifest? Nie ma czystego standardowego domu. Dlaczego zdjęcia to nie po prostu pliki? Wolumen i ekonomia przestrzeni. Dlaczego External ID? Inny system potrzebuje stabilnego identyfikatora ponad granicą. Dlaczego właścicielem Work Orders jest użytkownik integracyjny? Własność nie decyduje tu o dostępie, a ślad audytowy pozostaje uczciwy. Dlaczego odbiorca jest wciąż otwarty? Nie odpowiedzieliśmy jeszcze na dość pytań. Linie są wynikiem; wytworzyły je decyzje.

Oto więc nawyk, z którym chcę, żeby udało ci się wyjść z rozdziału 3. Wskaż cokolwiek w modelu fizycznym i zapytaj: dlaczego? Dlaczego ten obiekt, ten typ, ta relacja, ten właściciel, to miejsce, ta reguła? Powinno dać się prześledzić odpowiedź wstecz: od konfiguracji do modelu fizycznego, do modelu logicznego, do wymagania biznesowego. Jeśli się nie da, ktoś projektował z poziomu Konfiguracji.

I pewnie zauważasz liczby, których jeszcze w pełni nie przerobiliśmy: dostawy na partnera, pozycje, zdjęcia, retencja, archiwizacja. Dobrze. Zapytaj o liczbę zer, zanim zamkniesz projekt: model, który pięknie działa przy pięćdziesięciu tysiącach rekordów, może zachowywać się zupełnie inaczej przy pięciuset milionach. To część 2.

Poza egzaminem: co zmienia AI. Daj AI opis Steve Trucking, a w kilka sekund wytworzy schemat: konto, Work Order, obiekty niestandardowe, pola, nawet metadane do wdrożenia. To fantastyczny akcelerator i to nie jest przegląd. Zadanie architekta przesuwa się na sprawdzanie mapowań i ich konsekwencji: dopasowania, licencji, własności, cyklu życia, skali, tożsamości, bezpieczeństwa i tego, co zostaje poza platformą. AI to rakieta nośna; nie mówi ci, czy lecisz we właściwym kierunku.

Co tu decyduje architekt

• Jak każde pojęcie biznesowe mapuje się na Salesforce: obiekt standardowy, obiekt niestandardowy albo coś poza core.
• Które identyfikatory, pola i relacje implementują znaczenie biznesowe, nie zmieniając go po cichu.
• Jakie zachowanie platformy i jakie licencje przychodzą z przyjętym modelem standardowym.
• Które decyzje o własności, cyklu życia, spójności, przestrzeni i skali muszą zapaść, zanim projekt będzie kompletny.
• Które pytania pozostają jawnie otwarte, zamiast chować się za arbitralnym wyborem implementacyjnym.

Na początku tego rozdziału zapytaliśmy, jak model powinien żyć w Salesforce. To jest architektura danych Salesforce: nie tworzenie obiektów, nie zapamiętywanie Konfiguracji, nie rysowanie ładniejszych prostokątów, ale świadome dopasowanie modelu biznesowego do kształtu platformy. Każda struktura to zobowiązanie. Podejmuj te, które potrafisz wyjaśnić.

Do zgłębienia

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) i WorkType (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Opis Steve Trucking (po angielsku).