Spójność 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ł 9 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Własność i cykl życia · Dalej: Zaprojektuj fizyczny model w Salesforce

Pytanie, na które odpowiada ten moduł: jak utrzymać spójność danych i ile kosztuje każda warstwa?

Wszyscy chcą czystych danych. Nigdy nie byłem na spotkaniu o wymaganiach, na którym ktoś powiedziałby: „Najbardziej chcielibyśmy niespójnych danych”. Spór zaczyna się później: gdzie egzekwujemy reguły? Na ekranie? Pole wymagane? Lista wyboru, reguła sprawdzania poprawności, reguła duplikatów, Flow, Apex? Wszystkie pomagają. Nie są wymienne, a każda warstwa ma swój koszt.

Moja ogólna zasada to przesuwać regułę tak nisko, jak to rozsądnie możliwe. Jeśli wartość może być tylko jedną z pięciu rzeczy, nie pozwalaj ludziom wpisywać czegokolwiek, żeby potem sprzątać automatyzacją. Jeśli dwa rekordy nigdy nie mogą mieć tego samego identyfikatora, nie polegaj na tym, że ktoś to zauważy w raporcie. Jeśli reguła musi obowiązywać niezależnie od tego, czy rekord przychodzi z ekranu, API, integracji, importu danych czy od agenta, nie egzekwuj jej tylko w interfejsie. Im bliżej danych leży reguła, tym trudniej ją obejść. Nazywam to drabiną spójności.

Szczebel pierwszy: typ pola i słownictwo

Pierwsza reguła spójności to ta z modułu 6: wybierz właściwy typ. Data to Data, moment to Data/godzina, pieniądze to Waluta. To spójność, zanim ktokolwiek napisze regułę.

Zrób ze statusu dostawy pole tekstowe, a dostaniesz Delivered, delivered, DELIVERED, Complete, Done i Dropped off, a ktoś będzie musiał ustalić, czy te sześć znaczy to samo. Albo zdefiniuj słownictwo raz: Dostarczona, jedna wartość, jedno znaczenie. Zrób z niego ograniczoną listę wyboru, żeby odrzucała wszystko spoza listy, nawet przez API, i globalny zestaw wartości, gdy kilka pól dzieli tę listę (szczegóły w module 6).

Ale nie używaj listy wyboru tylko po to, żeby powstrzymać ludzi przed wpisywaniem. Czy to naprawdę wartość, czy inna encja? Dziewięć centrów dystrybucyjnych, każde z nazwą, może wyglądać jak lista wyboru; dziewięć z adresami, kierownikami, przepustowością i ciężarówkami to rekordy. Reguła powinna wzmacniać model, a nie łatać zły. A jeśli to naprawdę kontrolowane słownictwo, kontroluj je na poziomie pola. Nie dopuszczaj chaosu, żeby potem budować Flow, który zamienia AZ, Arizona, Ariz i Phoenix area na wartość, której chciało się od początku.

Szczebel drugi: wymagane i unikalne

Wymagane i Unikalne kuszą, bo są proste: zaznacz pole, problem rozwiązany. Czasem. Jeśli każda ciężarówka ma numer floty od dnia utworzenia, a żadne dwie nie mają tego samego, oba pola wyrażają prawdziwe reguły biznesowe. To mocna spójność.

Ale gdy platforma egzekwuje regułę, nie obchodzi jej, że twój proces ma wyjątek we wtorek po południu. Używam tego przykładu na zajęciach od lat. Obiekt istnieje od jakiegoś czasu, z dużą liczbą rekordów. Ktoś dodaje pole i zaznacza Wymagane. Testuje tworzenie rekordu: działa pięknie. Potem sobotnia noc, wdrożenie, uruchamiają się testy, a stara klasa testowa tworzy obiekt bez nowego pola. Bum. Albo ktoś edytuje stary rekord sprzed powstania pola. Albo integracja wysyła ten sam ładunek, co od pięciu lat. Bum. „Ale przecież nie zmienialiśmy tego pola”. Platformy to nie obchodzi: zmieniono umowę dotyczącą tego, czym jest prawidłowy rekord. Nowa reguła nie dotyczy tylko nowych danych; zmienia to, co można zrobić ze starymi.

Szczebel trzeci: reguły sprawdzania poprawności

Reguły sprawdzania poprawności pozwalają powiedzieć dużo bogatsze rzeczy. Jeśli status to Dostarczona, rzeczywisty czas dostawy musi być wypełniony. Jeśli przystanek to instalacja, lista kontrolna musi być kompletna, zanim przystanek będzie można zamknąć. Działają przy zapisie rekordu, więc chronią rekord niezależnie od tego, czy zapisano go ze strony, przez API, importem danych, integracją czy przez agenta. O to chodzi. Jeśli reguła ma chronić rekord, umieść ją tam, gdzie spotyka ją każdy zapis.

Mają też zęby. To ich siła i ich koszt.

Problem starych rekordów

Tu robi się nieprzyjemnie. Masz milion rekordów i dziś dodajesz regułę: czas dostawy nie może być wcześniejszy niż wyjazd na trasę. Rozsądne. Ale dwadzieścia tysięcy starych rekordów ją łamie, dzięki migracji sprzed siedmiu lat. Użytkownik otwiera jeden z nich i zmienia numer telefonu. Zapisz. Reguła się uruchamia. „Zmieniłem numer telefonu. Dlaczego mówicie mi o czasie dostawy z 2019 roku?”. Uczciwe pytanie.

Reguła sprawdzania poprawności nie powinna więc mówić tylko, co musi być prawdą. Powinna mówić, kiedy to egzekwować. Funkcje takie jak ISNEW() i ISCHANGED() pozwalają ograniczyć regułę do nowych rekordów albo do zapisów, w których naprawdę zmieniają się odpowiednie pola (Validation Rule Considerations (opens in a new tab), po angielsku).

Ale rekord nie zmienia się tylko wtedy, gdy edytuje go człowiek, a wiele powodów jest poza twoją kontrolą. Integracja aktualizuje status w nocy. Przepływ wstawia datę. Kierownik przepisuje terytorium i właściciel zmienia się na dziesięciu tysiącach rekordów. Ktoś edytuje pozycję dostawy, roll-up na dostawie się przelicza, a to zapisuje dostawę, więc reguła sprawdzania poprawności dostawy uruchamia się dla użytkownika, który jej nawet nie dotknął (Roll-Up Summary Field (opens in a new tab), po angielsku, ostrzega, że błędy walidacji mogą się pojawić na rekordzie szczegółowym albo nadrzędnym). Każdy z tych zapisów trafia na twoją nową regułę. Przy każdej nowej regule zapytaj więc: czy ta reguła powinna dotyczyć tego zapisu?

Oto możliwości, a ty wplatasz je w regułę:

• Zawsze, przy każdym zapisie. Słusznie, gdy reguła naprawdę dotyczy rekordu, a stare dane ją spełniają. Ale wiedz, co znaczy „każdy zapis”: zadanie wsadowe, które zmienia tylko właściciela, albo dowolna drobna edycja dowolnego pola gdziekolwiek na rekordzie też musi przez nią przejść.
• Tylko dla nowych rekordów, z ISNEW(). Reguła sprawdza rekord raz, przy utworzeniu, i nigdy więcej. Przeszłość zostaje taka, jaka była, ale przyszłość też: późniejsza edycja może sprawić, że nowy rekord złamie regułę, i nikt tego nie zatrzyma. Jeśli to ma znaczenie, połącz ją z następną.
• Tylko gdy zmieniają się pola, których dotyczy, z ISCHANGED(). Edycja numeru telefonu nie budzi reguły o czasie dostawy.
• Nie dla określonych zapisujących. Uprawnienie niestandardowe (custom permission), sprawdzane w formule jako $Permission, pozwala przejść użytkownikowi integracyjnemu albo migracji danych, a ludzie nadal muszą spełniać regułę (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), po angielsku). Nadawaj je świadomie i nielicznym.
• Od określonej daty, porównując CreatedDate z dniem, w którym reguła weszła w życie, gdy „nowy” znaczy „odkąd zaczęliśmy to egzekwować”. W przeciwieństwie do ISNEW() sprawdza te rekordy przy każdym późniejszym zapisie, więc obowiązuje to samo ostrzeżenie: drobna zmiana, na przykład wsadowa aktualizacja właściciela, może się nie udać na rekordzie, który się rozjechał.

Dodajesz regułę do rekordów, które już masz? Przemyśl konsekwencje, zanim ją włączysz. Każdy istniejący rekord musi ją teraz spełnić przy następnym zapisie, a ten zapis może przyjść z nieoczekiwanego miejsca: z nocnej integracji, wsadowej zmiany właściciela, roll-upu, masowej aktualizacji z widoku listy. Które z nich na nią trafią i co stanie się z tym zadaniem, gdy jeden rekord się nie zapisze? Sekcja Zanim ją włączysz opisuje kolejność, której używam.

Nie przepisuj historii, żeby zadowolić regułę

A co z dwudziestoma tysiącami starych rekordów? Jeśli dane są złe, a znasz właściwe wartości, popraw je. Ale widziałem inny rodzaj „naprawy”: nikt nie zna historycznej prawdy, rekordy muszą po prostu przejść, więc aktualizuje się je wartościami, które spełniają dzisiejszą regułę. Nie podoba mi się to. Aktualizacja starych rekordów, żeby były zgodne, zmienia LastModifiedDate i niszczy kluczowe informacje historyczne, a wymyślanie wartości oznacza udawanie, że wiemy coś o przeszłości, czego nie wiemy. Daj regule obejście dla rekordów, które ją poprzedzają, zamiast przepisywać historię. Może to być brzydkie, ale jest uczciwe.

Walidacja w interfejsie to nie walidacja danych

Ustaw pole jako wymagane w układzie strony, a użytkownicy nie zapiszą bez niego. Potem nocna integracja wstawia 50 000 rekordów. Czy skorzystała z twojej strony? Nie. Import masowy, klient API i agent też nie. Wymaganie w interfejsie chroni ten ekran, a nie dane. Walidację pól w dynamicznych formularzach da się obejść tak samo. Zapytaj więc: którędy mogą wchodzić te dane? Lightning, portal, aplikacja mobilna, integracja, API, import masowy, Flow, Apex, agent. Im więcej drzwi, tym mniej ufam regule, która pilnuje tylko jednych.

Szczebel czwarty: reguły duplikatów

Teraz przechodzimy od spójności wewnątrz rekordu do spójności między rekordami. Acme Corporation, ACME Corp, Acme Inc.: czterech klientów czy jeden? Żadna reguła pola na to nie odpowie. Reguły dopasowania określają, jak porównuje się rekordy; reguły duplikatów decydują, co się dzieje, gdy znaleziony zostanie prawdopodobny duplikat: dopuść z ostrzeżeniem, zablokuj albo zgłoś w raporcie. Możesz mieć do pięciu aktywnych reguł duplikatów na obiekt i do trzech reguł dopasowania w każdej, a klucze dopasowania zawężają każde porównanie do 100 najbardziej prawdopodobnych duplikatów (Things to Know About Duplicate Rules (opens in a new tab), po angielsku).

Ich kosztem jest tarcie. Jeśli każde konto, które tworzy handlowiec, pokazuje Znaleziono możliwy duplikat, czasem to dokładnie to, czego chcesz, a czasem ludzie uczą się klikać dalej bez czytania. Prawidłowe rekordy mogą wyglądać podobnie, a integracja może potrzebować innego zachowania niż człowiek. A ostrzeżenie należy do samego Salesforce: jego alert i lista możliwych duplikatów mogą nie pasować do zbudowanego przez ciebie niestandardowego ekranu, a gdy zapis jest bezgłowy (headless), czyli z integracji, ładowania danych czy od agenta, w ogóle nie ma ekranu, na którym można by je pokazać. Zdecyduj więc, jak duplikat wychodzi na jaw na każdej ścieżce: ostrzeżenie dla człowieka, zablokowany zapis i błąd dla API albo opcja Report i zestawy zduplikowanych rekordów (duplicate record sets) do późniejszego przejrzenia przez kogoś. Dobra architektura to nie maksymalne egzekwowanie; to właściwe egzekwowanie.

I sprawdź, których drzwi reguła duplikatów naprawdę pilnuje (Things to Know About Duplicate Rules (opens in a new tab), po angielsku). Przez API i narzędzia importu danych nikt nie widzi ostrzeżenia: reguła ustawiona na alert po prostu blokuje zapis. Niektóre ścieżki całkowicie pomijają reguły: Quick Create, przycisk Undelete, ręczne scalanie, rekordy dodane przez Lightning Sync albo Einstein Activity Capture. A rekordy zapisywane w tym samym momencie nie są porównywane ze sobą, tylko z rekordami, które już są w Salesforce. Załaduj plik, w którym ten sam klient jest dwa razy, a oba wiersze mogą przejść. Reguła duplikatów to dobra siatka. To nie zamek w drzwiach.

Wiedza egzaminacyjna. Reguły duplikatów nie porównują ze sobą rekordów zapisywanych w tym samym momencie, tylko z rekordami, które już są w Salesforce. Przez API i narzędzia importu nie ma alertu: duplikat wychwycony przez regułę po prostu nie zostaje zapisany. A zapis i wszystko, co uruchamia, działają jako jedna transakcja: jeśli którakolwiek część się nie powiedzie, całość jest wycofywana.

Jedna granica. Reguły duplikatów utrzymują w czystości jeden org. Nie rozwiązują tożsamości w przedsiębiorstwie. Jeśli Salesforce ma Acme Corporation, ERP ma ACME-10382, a system rozliczeń klienta 77193, reguła duplikatów nie powie ci, że to ta sama firma. To dane podstawowe, rozdział 6.

Szczebel piąty: automatyzacja

Niektóre reguły są zbyt złożone na niższe szczeble: potrzebują powiązanych rekordów, innego systemu, rekordów zależnych, wieloetapowego procesu. To Flow, Apex, czasem logika integracji. (Nie reguły przepływu pracy ani Process Builder; nie są już wspierane). Automatyzacja jest potężna i droższa: więcej ruchomych części, więcej testowania, więcej obsługi błędów, więcej sposobów, w jakie jedna automatyzacja może potknąć się o drugą. A kod przynosi własne błędy. Jeśli typ pola może to wyegzekwować, nie piszę Apex. Jeśli reguła sprawdzania poprawności wyraża to jasno, nie buduję Flow tylko dlatego, że Flow istnieje. Nie rozwiązuj problemu pola silnikiem procesów.

Wszystko albo nic: gdy rekordy zmieniają się razem

Dotąd każdy szczebel chronił jeden zapis. Ale rekordy zmieniają się razem: dostawa i jej pozycje, zamówienie i jego linie, przepływ, który aktualizuje trzy obiekty. Tu platforma daje ci mocną gwarancję. Zapis i wszystko, co uruchamia, triggery, przepływy, klasy, które wywołują, działają jako jedna transakcja: jeśli którakolwiek część się nie powiedzie, całość jest wycofywana i nic nie zostaje zatwierdzone (Apex Transactions (opens in a new tab), po angielsku). Nie dostaniesz połowy dostawy.

Praca masowa to wyjątek, który sam wybierasz. Ładowanie danych albo metoda Apex Database mogą dopuścić częściowy sukces: dobre rekordy się zapisują, złe wracają z błędami i ktoś musi się nimi zająć (DML Statements vs. Database Class Methods (opens in a new tab), po angielsku). Przy ładowaniu miliona wierszy to często słuszne, ale wtedy spójność staje się procesem: kto czyta plik błędów i co dzieje się z rekordami, które się nie zapisały?

A do tego dochodzi czas. Dwa zapisy w tym samym momencie mogą oba przejść sprawdzenie, którego każdy z osobna by nie przeszedł. Przepływ, który szuka istniejącego zamówienia, a potem je tworzy, może przepuścić dwa, a przed chwilą widzieliśmy, że reguły duplikatów nie porównują rekordów zapisywanych w tym samym czasie. Pole oznaczone jako Unique (unikalne) albo External ID jest sprawdzane przez platformę przy każdym zapisie, więc wygrywa tylko jeden z nich. To kolejny powód, żeby przesuwać unikalność w dół, do pola. Blokady, rywalizacja o zasoby i ponowienia to osobny temat; rozdział 11, Transakcje, współbieżność i niezawodność, wchodzi w niego głęboko.

Przesuwaj regułę w dół, dopóki tam pasuje

„Tak nisko, jak to rozsądnie możliwe” nie znaczy „zawsze najniżej”. Jeśli pole jest wymagane dopiero wtedy, gdy szansa sprzedaży osiągnie określony etap, ustawienie go jako wymaganego w schemacie jest błędem; reguła jest warunkowa, więc właściwym szczeblem jest reguła sprawdzania poprawności. Jeśli duplikat powinien ostrzegać człowieka, a zatwierdzona integracja ma własne uzgadnianie, zaprojektuj obie ścieżki. Cel: najniższa warstwa, która poprawnie odwzorowuje regułę biznesową.

Każda warstwa ma koszt

Click to enlarge

Oto kompromis, który chcę ci pokazać. Typy pól i kontrolowane wartości są proste i mocne, ale tylko w tym, co pole potrafi wyrazić. Wymagane i Unikalne są toporne: gdy są włączone, każdy zapis musi je spełnić. Reguły sprawdzania poprawności wyrażają bogatsze warunki, ale mogą blokować edycję starych rekordów i zaskoczyć przy wdrożeniu. Reguły duplikatów chronią między rekordami, ale dodają tarcie użytkownikom i integracjom. Automatyzacja obsłuży wszystko, ale każe ci być właścicielem orkiestracji, błędów, testów i wydajności. Nie ma darmowej warstwy. Wybieraj warstwę każdej reguły, wiedząc, jak zawodzi.

Zanim ją włączysz

Dodanie reguły do istniejącego orgu to wdrożenie, a nie pole wyboru. Ile rekordów ją dziś łamie i dlaczego? Czy naprawdę są złe? Czy możemy znać właściwą wartość? Czy reguła jest prawdziwa historycznie, czy dopiero od teraz? Które integracje, testy i automatyzacje na nią trafią? Dobra kolejność: zmierz, wyczyść to, co potrafisz udowodnić jako błędne, ogranicz zakres reguły, dodaj świadome obejście dla prawidłowej historii, przetestuj każdą ścieżkę zapisu, potem egzekwuj. Mierzenie i czyszczenie to osobne dyscypliny, profilowanie, standaryzacja, monitorowanie, opieka nad danymi (stewardship), i omawia je rozdział 5, Jakość danych i ład danych. Dużo lepsze niż zaznaczenie pola w piątek i odkrywanie konsekwencji w sobotnią noc.

Poza egzaminem: co zmienia AI. Agent może tworzyć rekordy szybciej niż ktokolwiek, i równie szybko złe rekordy. „Użytkownicy wiedzą, że tak się nie robi” to żadna ochrona, gdy użytkownikiem jest agent. Umieść ważne reguły w warstwie danych, gdzie spotyka je każdy zapisujący, żeby agent nie musiał pamiętać niepisanych zasad firmy.

Steve Trucking: chroń dostawę

Weźmy dostawę. Jej status pochodzi z jednego słownika: lista wyboru, ograniczona. Numer zamówienia partnera detalicznego musi być unikalny w obrębie partnera, więc to External ID, oznaczony jako unikalny, używany do upsertu manifestu. Rzeczywisty czas dostawy jest wymagany, gdy status to Dostarczona: reguła sprawdzania poprawności ograniczona do tej zmiany. Przystanku z instalacją nie można zamknąć, dopóki jego lista kontrolna nie jest kompletna, a wymagane zdjęcia wykonane (dla zmywarki: przyłącze wody, odpływ i poziomowanie): reguła sprawdzania poprawności albo automatyzacja, jeśli musi sprawdzić zdjęcia przechowywane poza platformą. To samo zamówienie przychodzące dwa razy z ponownie wysłanego manifestu wyłapie External ID; dwa różne zamówienia, które wyglądają podobnie, to pytanie o dopasowanie.

Zwróć uwagę, że nie powiedziałem „wrzuć je wszystkie do Flow”. Każda reguła stoi na własnym szczeblu. Dla każdej reguły zapytaj: jaka jest najniższa warstwa, która egzekwuje ją poprawnie dla każdej ważnej ścieżki zapisu?

Co tu decyduje architekt

• Na którym szczeblu należy każda reguła: typ pola, kontrolowane słownictwo, wymagane albo unikalne, reguła sprawdzania poprawności, reguła duplikatów czy automatyzacja.
• Które ścieżki zapisu trzeba chronić: interfejs, portal, aplikację mobilną, integracje, importy masowe, API, automatyzację i agentów.
• Czy nowa reguła dotyczy rekordów historycznych, czy jest ograniczona do nowych i zmienianych danych z obejściem dla przeszłości.
• Czy istniejące złe dane da się poprawić na podstawie dowodów, zamiast przepisywać je, żeby przechodziły.
• Ile tarcia, złożoności i utrzymania jest warta reguła.

Czyste dane nie biorą się z proszenia ludzi, żeby wprowadzali dobre dane. Biorą się z architektury, która sprawia, że właściwe działanie jest łatwe, złe trudne, a ważne reguły trudno obejść. Dalej złożymy ten rozdział w całość na wycinku Steve Trucking.

Do zgłębienia

• Pomoc Salesforce, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) i Roll-Up Summary Field (opens in a new tab) (po angielsku), sprawdzono 2026-10-13.
• Pomoc Salesforce, Picklist Limitations (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Pomoc Salesforce, Validation Rule Considerations (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Pomoc Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: limity, ścieżki, na których reguły nie działają, zapisy przez API i import blokowane bez alertu, równoczesne zapisy nieporównywane.
• Apex Developer Guide, Apex Transactions (opens in a new tab) i DML Statements vs. Database Class Methods (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: jedna transakcja jest wycofywana jako całość; metody Database mogą dopuścić częściowy sukces.
• Pomoc Salesforce, Workflow Rules & Process Builder End of Support (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.