Pola to też architektura

🌐 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ł 6 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Wybierz właściwy obiekt · Dalej: Relacje mają konsekwencje

Pytanie, na które odpowiada ten moduł: jak Salesforce powinien fizycznie odwzorować każdy element danych?

Utworzenie pola zajmuje mniej więcej minutę. Nowe pole, wybierz typ, nadaj nazwę, Dalej, Dalej, Zapisz. Właśnie dlatego pól nie traktuje się jak architektury.

Wejdź do orgu, który istnieje od dziesięciu lat, i otwórz konto. Pięćset pól. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Trzy różne numery klienta. Pole wyboru, którego nikt nie usunie, bo nikt nie wie, która integracja wciąż go używa. Utworzenie pola zajęło minutę. Życie z nim zajmuje lata. Myśl przewodnia tego modułu jest więc prosta: pole to decyzja architektoniczna. Nie zawsze duża, ale każde pole koduje coś o znaczeniu, zachowaniu, tożsamości albo jakości danych, a pola, tak jak obiekty, łatwo dodać i zaskakująco trudno usunąć.

Co te dane naprawdę znaczą?

W rozdziale 2 nadaliśmy encjom atrybuty: dostawa ma zaplanowane okno, ciężarówka ma VIN. Teraz je implementujemy i tu ludzie skaczą prosto do „pola tekstowego”. Zaczekaj. Przed typem chcę wiedzieć, co dane znaczą. Czy to liczba, czy identyfikator, który akurat ma cyfry? Data czy moment w czasie? Dowolny tekst czy jedna z zatwierdzonych wartości? Wprowadzane przez człowieka czy należące do innego systemu? Mogą się zmieniać? Muszą być unikalne? Mogą ich brakować? Czy w ogóle trzeba je przechowywać, czy wyliczać? To nie są pytania o Konfigurację. To pytania o architekturę danych, a typ pola przychodzi po odpowiedzi na nie.

Liczba to nie zawsze liczba

Steve Trucking nadaje każdej ciężarówce numer floty, powiedzmy 001247. Pole liczbowe? Raczej nie. Czy dodajemy numery floty? Czy ciężarówka 1247 minus ciężarówka 1246 to jedna ciężarówka? To identyfikator, który akurat zawiera cyfry, a pole liczbowe nawet usunęłoby wiodące zera. To samo dotyczy kodów pocztowych, kodów produktów, numerów kont i numerów przesyłek. To, jak wygląda wartość, nie mówi ci, co znaczy. Wybieraj typ według potrzebnego zachowania, a nie według tego, jak wyglądają przykładowe dane.

Czy człowiek musi to identyfikować?

Każdy obiekt niestandardowy dostaje pole Name, a pierwsza decyzja to tekst albo autonumer. Pytam: czy człowiek musi identyfikować tę rzecz? Ludzie znają partnera detalicznego po nazwie, a ciężarówkę po numerze floty. Ale manifest, który system generuje co noc? Nikt nie powinien wpisywać „Manifest 10-02 numer 3” tylko dlatego, że Salesforce wymagał pola Name. Daj mu autonumer. Tylko nie myl tego wygenerowanego Name z tożsamością rekordu: autonumer pomaga użytkownikom, identyfikator Salesforce identyfikuje rekord, a własny numer manifestu partnera detalicznego może identyfikować tę samą rzecz w wielu systemach. Trzy różne zadania.

Ekran szczegółów

Wybierz typ, kliknij Dalej, a Konfiguracja zapyta o szczegóły. To ekran, na którym zapada większość decyzji z tego modułu, zwykle w pośpiechu.

Nowe pole niestandardowe (New Custom Field), krok 2: szczegóły (zrzut ekranu, 2026-10-12). Pełny rozmiar

Dwa okienka wyglądają podobnie, a robią co innego. Description (opis) jest dla ludzi, którzy utrzymują org, a teraz także dla narzędzi AI, które go czytają: co pole znaczy, kto jest jego właścicielem, skąd pochodzi. Help Text (tekst pomocy) jest dla użytkownika przed ekranem: co tu wpisać. Wypełnij oba. Potem przychodzą Required (wymagane), Unique (unikalne) i External ID, a każde z nich zasługuje na własną sekcję. Pod nimi Default Value (wartość domyślna) może być formułą, więc nowy rekord może zacząć od sensownej wartości zamiast od pustego pola.

Wymagane to większa decyzja, niż się wydaje

W kreatorze pola jest małe pole wyboru z etykietą Wymagane i, jak widzieliśmy w rozdziale 1, może być bombą zegarową. Masz obiekt od pięciu lat i dwa miliony rekordów, a teraz ktoś decyduje, że nowe pole musi zawsze mieć wartość. Co z dwoma milionami rekordów, które powstały wcześniej? Z integracjami, które go nie wysyłają? Z automatyzacją, która tworzy rekord, zanim wartość jest znana? Z procesem, w którym wartość pojawia się dopiero trzy kroki później?

„Wymagane” brzmi jak decyzja o jakości danych i czasem nią jest. Ale to, kiedy wartość staje się znana, jest częścią procesu biznesowego. Nie zaznaczaj więc Wymagane dlatego, że ktoś mówi „zawsze tego chcemy”. Zapytaj, kiedy wartość jest znana, kto ją dostarcza i co się dzieje, gdy jej nie ma. Umieścimy to na pełnej drabinie spójności w module 7.

Unikalne też coś znaczy

Jeśli oznaczam pole jako unikalne, składam deklarację o biznesie: nie „zwykle się nie powtarza”, ale „dwa rekordy nigdy nie mogą mieć tej wartości”. To mocne. A ekran każe ci zdecydować jeszcze jedno: czy „ABC” i „abc” to ta sama wartość, czy różne? Bez rozróżniania wielkości liter to bezpieczniejszy wybór domyślny dla wszystkiego, co wpisuje człowiek. Obowiązuje tu zasada kluczy z rozdziału 2, unikalny, niezmienny, bez znaczenia, nigdy dane osobowe. Jeśli ktoś mi mówi, że e-mail pracownika jest unikalny, zaczynam pytać: czy może się zmienić, czy ktoś może odejść i wrócić, czy adresy mogą być ponownie używane, co się stanie po przejęciu? E-mail może być przydatny, nawet dziś unikalny. To nie czyni go dobrym identyfikatorem.

External ID: tożsamość ponad granicą

Tu External ID zarabiają na siebie. Ekran dobrze to opisuje: pole staje się „unikalnym identyfikatorem rekordu z systemu zewnętrznego”. ERP ma klienta 873492; Salesforce ma własny identyfikator rekordu. Gdy ERP wysyła aktualizację, skąd wiemy, do którego rekordu należy? Oznacz pole jako External ID, a integracja może wykonywać na nim upsert: utworzyć rekord, jeśli nie istnieje, zaktualizować, jeśli istnieje (Upsert a Record Using an External ID (opens in a new tab), po angielsku). A gdy ładujesz rekordy podrzędne, możesz wskazać rodzica jego External ID, zamiast najpierw odpytywać o identyfikator Salesforce. Lubię mówić, że pozwalasz Salesforce zrobić wyszukiwanie za ciebie. Bardzo potężne.

Zwróć uwagę, że numer z ERP nie staje się tożsamością rekordu w Salesforce. To atrybut, a rekord może nieść ich kilka: identyfikator klienta z ERP, stary identyfikator, identyfikator partnera. To w porządku. Jeden podmiot biznesowy może być znany różnym systemom inaczej. Pytanie architektoniczne brzmi: który system jest właścicielem każdego identyfikatora i jaką składa obietnicę: oznacz go jako unikalny tylko wtedy, gdy biznes naprawdę to gwarantuje.

Typ po typie

Teraz same typy. Otwórz Nowe pole (New Field) na dowolnym obiekcie, a Konfiguracja pokaże ci całą listę, pogrupowaną tak, jak przez nią przejdę: pola, które Salesforce wylicza za ciebie, pola relacji, a potem typy danych.

Konfiguracja, Nowe pole niestandardowe, krok 1: typy danych (zrzut ekranu, 2026-10-12). Pełny rozmiar

Oto cała lista w skrócie, z jedną rzeczą, którą chcę, żebyś zapamiętał o każdym typie.

Grupa	Typ	Zapamiętaj
Wyliczane	Autonumer (Auto Number)	Do 30 znaków, z czego 20 na prefiks lub sufiks; etykieta dla ludzi, a nie tożsamość rekordu
	Formuła (Formula)	Wyliczana przy odczycie, nie przechowywana; 3900 znaków
	Podsumowanie zbiorcze (Roll-Up Summary)	Liczba, suma, minimum lub maksimum rekordów szczegółowych; tylko master-detail
Relacje	Lookup, Master-Detail, External Lookup	Moduł 7
Dane	Pole wyboru (Checkbox)	Prawda albo fałsz, z wybraną przez ciebie wartością domyślną; w przepływach i tak może pojawić się null
	Liczba, procent, waluta	Reguły zaokrąglania; wiodące zera usuwane; 15 miejsc po przecinku
	Data, data/godzina, godzina	Dzień, moment albo pora dnia; momenty przechowywane w UTC
	E-mail, telefon, URL	Formatowane i sprawdzane przy zapisie: 80, 40 i 255 znaków
	Geolokalizacja, adres	Pola złożone, które kosztują więcej niż jedno pole: 3 i 9
	Lista wyboru, wielokrotnego wyboru	Kontrolowane słownictwo, którego właścicielem jest administrator
	Tekst, obszar tekstowy, długi, sformatowany, szyfrowany	Do 255 znaków przy rekordzie i z możliwością indeksowania; powyżej brak indeksu i filtrowania

Pola, które wylicza Salesforce

Autonumer (Auto Number) przypisuje każdemu nowemu rekordowi kolejny numer w sekwencji, w zdefiniowanym przez ciebie formacie, na przykład T-{000000}. Używaj go, gdy człowiek potrzebuje przyjaznego uchwytu, a nikt nie powinien musieć go wymyślać. Cała wartość ma do 30 znaków, z czego 20 jest zarezerwowanych na prefiks lub sufiks. Pamiętaj tylko z rozdziału 2: to etykieta dla ludzi, a nie tożsamość rekordu, a numery nie zawsze idą ściśle po kolei.

Pola formuły (Formula) wyliczają wartość z innych pól. Są potężne i są wyliczane przy odczycie rekordu, a nie przy zapisie, więc nie ma niczego przechowywanego, co mogłoby się zestarzeć. Wybierasz, co formuła zwraca: pole wyboru, walutę, datę, datę/godzinę, liczbę, procent, tekst albo godzinę.

Nowe pole niestandardowe, formuła: wybór typu zwracanego (zrzut ekranu, 2026-10-12). Pełny rozmiar

Potem piszesz samą formułę, z polami, operatorami i funkcjami, i sprawdzasz jej składnię. Zwróć uwagę na przycisk Use Formula Assistant: AI Salesforce pomoże ci teraz napisać formułę. Korzystaj z niego, a potem przeczytaj, co napisał. To ty jesteś właścicielem formuły, nie asystent.

Edytor formuł z asystentem formuł (Formula Assistant) (zrzut ekranu, 2026-10-12). Pełny rozmiar Formuła może mieć do 3900 znaków i nie może przekroczyć 15 000 bajtów po zapisaniu lub skompilowaniu; długą formułę można rozbić na kilka pól formuły, które odwołują się do siebie nawzajem. Nie można w nich używać długich obszarów tekstowych, pól szyfrowanych ani pól Description.

Pola podsumowania zbiorczego (Roll-Up Summary) siedzą na rekordzie nadrzędnym i liczą, sumują albo biorą minimum lub maksimum jego rekordów szczegółowych. Działają tylko w relacji nadrzędny-szczegółowy (master-detail), co jest jednym z największych powodów, żeby w ogóle wybrać master-detail. Wrócimy do nich i do ich limitów w module 7.

Przechowywane czy wyliczane?

Czy w ogóle musimy przechowywać tę wartość? Jeśli mam ilość i cenę jednostkową, czy ktoś albo jakaś automatyzacja musi utrzymywać sumę? Może powinna ją wyliczać formuła: jedno źródło obliczenia, przeliczane przy odczycie, więc zmień ilość, a wynik pójdzie za nią. Formuły mają własne limity (rozmiar po zapisaniu i wyświetlana długość; Formula Field Limits and Restrictions (opens in a new tab), po angielsku), a złożone trudno utrzymać.

Ale czasem biznes nie chce dzisiejszej odpowiedzi. Chce odpowiedzi taką, jaka była. Jeśli reguła rabatowa zmieni się w przyszłym roku, czy zeszłoroczna faktura powinna nagle pokazywać inną kwotę? Oczywiście, że nie. Pytanie nie brzmi więc „czy Salesforce potrafi to wyliczyć?”. Brzmi: „czy to bieżące obliczenie, czy fakt historyczny?”. Fakty historyczne się przechowuje.

Pola relacji

Relacje wyszukiwania (Lookup), nadrzędny-szczegółowy (Master-Detail) i zewnętrzne relacje wyszukiwania (External Lookup) to też pola i to w nich linie twojego modelu stają się prawdziwe. Lookup to luźne powiązanie; master-detail wiąże życie, własność i bezpieczeństwo rekordu podrzędnego z rodzicem; zewnętrzna relacja wyszukiwania sięga do obiektu zewnętrznego z modułu 4, dopasowując po jego External ID. Wybór między nimi to decyzja na tyle duża, że dostała własny moduł.

Pole wyboru

Pole wyboru (checkbox) to najprostsze pole, jakie istnieje: prawda albo fałsz, zaznaczone albo nie. Idealne do faktu tak/nie o rekordzie: Is Active, Install Required, Signed For. Gdy je tworzysz, Salesforce każe ci wybrać jego wartość domyślną, zaznaczone albo niezaznaczone, i to prawdziwa decyzja: od niej zaczyna każdy nowy rekord, także rekordy tworzone przez integrację, która tego pola nie wysyła. Raporty i widoki list filtrują je jako True i False; narzędzia importu i cotygodniowy eksport pokazują je jako 1 i 0.

Jedna pułapka, którą warto znać. Pole na rekordzie ma dwie wartości, ale automatyzacja wokół niego może mieć trzecią. W przepływie zmienna typu checkbox, której nigdy nie ustawiono, ma wartość null, a nie false, a zapisanie jej do rekordu kończy się błędem (Trailblazer Community (opens in a new tab), po angielsku; zob. też znany problem Salesforce W-11208535 (opens in a new tab)). Wybierz sensowną wartość domyślną i spraw, żeby twoje przepływy i kod świadomie obsługiwały null.

Liczba, procent i waluta

Liczba (Number) przechowuje liczbę rzeczywistą i usuwa wszelkie wiodące zera, i właśnie dlatego numer floty taki jak 001247 nie jest liczbą. Salesforce zaokrągla pola liczbowe połówkowo od zera: 12,345 staje się 12,35, a −12,345 staje się −12,35. A w polach scalania zaokrągla według ustawień regionalnych użytkownika, a nie do liczby miejsc po przecinku ustawionej w polu.

Procent (Percent) przechowuje ułamek dziesiętny i pokazuje procent: wpisz 0,10, a zobaczysz 10%. Wartości tracą precyzję po 15 miejscach po przecinku.

Waluta (Currency) jest formatowana jako pieniądze, a w orgu z kilkoma walutami niesie kod waluty i może korzystać z kursów wymiany; z zaawansowanym zarządzaniem walutami (opens in a new tab) (po angielsku) szanse sprzedaży mogą używać kursów datowanych, czyli kursu z okresu, w którym transakcję zamknięto. Kursów datowanych używają tylko szanse sprzedaży i to, co wokół nich (produkty, harmonogramy, podziały i ich raporty); pola walutowe na innych obiektach zachowują jeden stały kurs. Uważaj na zaokrąglanie: bez miejsc po przecinku Salesforce po prostu obcina (23,5 staje się 23); z jednym lub więcej zaokrągla połówkowo od zera.

Data, data/godzina i godzina

Trzy typy, trzy różne znaczenia. Data (Date) to dzień: umowa wygasa w określonym dniu. Data/godzina (Date/Time) to moment: dostawa dotarła tego ranka o 9:42. Godzina (Time) to pora dnia bez żadnej daty: sklep otwiera się o 7:00, codziennie.

Pułapką jest moment. Salesforce przechowuje wartości daty/godziny w GMT (UTC). Godzina wpisana przez użytkownika jest odczytywana w jego strefie czasowej, przeliczana i zapisywana; gdy ktoś ją czyta, jest przeliczana znowu, na strefę czasową czytającego. Zwykle to dokładnie to, czego chcesz. Ale oto przykład, który daję na zajęciach: koordynator w Los Angeles rejestruje dostawę późno w niedzielę wieczorem, o 22:00 czasu pacyficznego. Pod spodem Salesforce zapisał poniedziałek rano, 5:00 GMT. Raport grupowany po dniach w innej strefie czasowej albo integracja czytająca surową wartość może umieścić tę niedzielną dostawę w poniedziałku. „Dzień, w którym to się stało” zależy od tego, czyj zegar zapytasz. Pilnuj stref czasowych użytkowników i zdecyduj, którą ma na myśli biznes.

I uważaj przy porównywaniu. Pod spodem data/godzina to jedna duża liczba: Apex czyta ją jako liczbę milisekund od 1 stycznia 1970, 00:00:00 GMT (Datetime Class (opens in a new tab), po angielsku). To precyzyjny moment, a nie dzień. Pytanie, czy dwie daty/godziny są równe (==), prawie nigdy nie robi więc tego, czego chcesz: 9:42:00 i 9:42:01 nie są równe, tak samo jak „poniedziałek” i dowolny moment w poniedziałek. Zamiast tego pytaj o zakres: od początku włącznie (>=) do końca włącznie (<=). „Każda dostawa w poniedziałek” to każda dostawa >= poniedziałek 00:00 i <= poniedziałek 23:59:59, w strefie czasowej, o której zdecydowałeś, że ma ją na myśli biznes.

I coś zabawnego: Salesforce nie przechowa byle jakiej daty. Prawidłowe daty sięgają od 1 stycznia 1700 do 31 grudnia 4000, a Salesforce podaje ten sam zakres dla dat i dat/godzin (Data Import Dates (opens in a new tab), po angielsku). Nawet krańce to momenty w GMT, więc dla użytkownika w czasie pacyficznym najwcześniejsza prawidłowa wartość to 16:00 31 grudnia 1699. Data założenia twojego towarzystwa historycznego może się nie zmieścić. A klasyczny trik „brak daty końcowej”, 31 grudnia 9999, zostanie odrzucony; jeśli potrzebujesz zastępczej daty w dalekiej przyszłości, musi przypadać w roku 4000 lub wcześniej.

E-mail, telefon i URL

To pola formatowane i robią więcej, niż tylko przechowują znaki. E-mail mieści do 80 znaków i jest sprawdzany pod kątem poprawnego formatu; na kontaktach i potencjalnych klientach kliknięcie go rozpoczyna e-mail na ten adres. Telefon (Phone) mieści do 40 znaków, jest formatowany jak numer telefonu i staje się klikalnym wybieraniem (click-to-dial), gdy org ma podłączony system telefoniczny. URL mieści do 255 znaków i otwiera się jako link. To platforma daje ci zachowanie za darmo i dlatego nigdy nie przechowywałbym numeru telefonu w zwykłym polu tekstowym.

Integracje też są sprawdzane. Wartość, która nie pasuje do formatu pola, na przykład źle zbudowany adres e-mail, nie przechodzi walidacji i odrzucany jest cały rekord, a nie tylko to pole. Kiedy więc dane systemu źródłowego są niechlujne, wyczyść je, zanim dotrą, albo zaplanuj, co zrobisz z rekordami, które się nie załadują.

Geolokalizacja i adres

Geolokalizacja (Geolocation) przechowuje szerokość i długość geograficzną. Pod spodem pole o nazwie Location__c to tak naprawdę dwie wartości, które możesz osobno czytać i ustawiać: Location__Latitude__s i Location__Longitude__s. I możesz po nim odpytywać: funkcje SOQL DISTANCE i GEOLOCATION znajdują rekordy w danym promieniu albo sortują je według odległości. „Każda otwarta dostawa w promieniu 25 mil od tej ciężarówki” to jedno zapytanie: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), po angielsku). Adres (Address) przechowuje cały adres: ulicę, miasto, stan lub województwo, kod pocztowy i kraj, a użytkownicy mogą wyszukać adres i mieć jego części wypełnione automatycznie.

Oba to pola złożone (compound fields): jedno pole na ekranie, kilka pod spodem. I kosztują więcej niż jedno pole w limicie twojego obiektu: geolokalizacja liczy się jako trzy pola niestandardowe, a adres jako dziewięć. Na obiekcie, który już jest zatłoczony, to ma znaczenie.

Lista wyboru i wielokrotnego wyboru

Lista wyboru (picklist) kontroluje, co użytkownicy mogą wpisać: jedną wartość z listy, którą definiujesz. Status? Pewnie lista wyboru. Ale wartości to metadane i dodać ani zmienić je musi administrator. Nadal więc pytam, kto jest właścicielem wartości, jak często się zmieniają, czy kilka obiektów potrzebuje tej samej listy, czy wartości niosą własne informacje i czy słownictwo nie należy do innego systemu.

To, gdzie mieszkają wartości, też jest decyzją. Gdy lista jest używana raz, w jednym polu, trzymaj wartości w samym polu, na obiekcie; tak domyślnie robi Salesforce. Ale gdy ten sam zestaw wartości zaczyna się pojawiać w kilku miejscach, region na koncie, na dostawie i na magazynie, awansuj go do globalnego zestawu wartości, zanim kopie się rozjadą. Globalny zestaw wartości trzyma jedną listę dla nich wszystkich, do 1000 wartości, aktywnych i nieaktywnych łącznie (Picklist Limitations (opens in a new tab), po angielsku). Opis w samej Konfiguracji mówi, dlaczego to ważne: zestaw wartości „is restricted so users can’t add unapproved values through the API” (jest ograniczony, więc użytkownicy nie mogą dodawać niezatwierdzonych wartości przez API). Jedna lista, jeden właściciel i żadna integracja nie przemyci nowej pisowni.

Ten ostatni punkt to różnica między listą ograniczoną a nieograniczoną. Na ograniczonej liście wyboru dozwolone są tylko wartości zdefiniowane przez administratora, skądkolwiek przychodzą: użytkownik, import albo integracja, które wyślą cokolwiek innego, dostają błąd „bad value for restricted picklist field” i rekord nie zostaje zapisany. Na nieograniczonej liście wyboru użytkownicy nadal wybierają z listy na ekranie, ale API, importy i automatyzacja mogą wysłać dowolną wartość, a Salesforce ją zapisze i doda jako wartość nieaktywną (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), po angielsku). Tak org kończy z „Delivered”, „delivered” i „Dlvrd”. Globalne zestawy wartości są zawsze ograniczone. Moim wyborem domyślnym jest lista ograniczona; nieograniczona to świadomy wybór na sytuację, gdy wartości naprawdę należą do innego systemu, a wtedy ktoś odpowiada za sprzątanie nieaktywnych.

Konfiguracja, Picklist Value Sets: nowy globalny zestaw wartości (zrzut ekranu, 2026-10-12). Pełny rozmiar

Lista wielokrotnego wyboru (multi-select picklist) pozwala użytkownikowi wybrać kilka wartości, przechowywanych razem i rozdzielonych średnikami. Wygodna na ekranie, niezręczna wszędzie indziej: trudniej po niej filtrować, raportować i integrować, i nie można jej użyć w filtrze podsumowania zbiorczego. Kilka wartości dla jednego rekordu zwykle oznacza lekcję z rozdziału 2: jest tam obiekt podrzędny, który próbuje się wydostać.

Lista wyboru ma też o jedną wartość więcej, niż zdefiniowałeś: pustą. Rekord może stać bez wybranej wartości, i to łapie ludzi. W formule albo regule sprawdzania poprawności nie sprawdzisz listy wyboru samym ISBLANK; piszesz ISBLANK(TEXT(Field__c)) albo ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), po angielsku). Zdecyduj więc, co „brak wartości” znaczy dla każdej listy wyboru: czy jest dozwolony i co znaczy, gdy się zdarzy? Potem spraw, żeby twoje formuły, reguły sprawdzania poprawności i filtry go obsługiwały.

A czasem atrybut jest tak naprawdę encją. Ktoś prosi o listę wyboru centrów dystrybucyjnych. Jest ich dziewięć. Łatwizna. Potem dowiadujemy się, że każde ma adres, kierownika, godziny pracy, przepustowość, region i ciężarówki. To nie lista wyboru; to rzecz. Nie zamieniaj encji w listę wyboru tylko dlatego, że na razie jest ich niewiele. W pierwszym roku czujesz się świetnie, a w piątym okropnie. (Moduł 5 rozdziału 2 zawiera moje praktyczne zasady, kiedy lista zasługuje na własny obiekt).

Rodzina pól tekstowych

Uczę, że tekst jest dwojakiego rodzaju, a granica między nimi to 255 znaków.

Do 255: przechowywany razem z rekordem. Tekst (Text) mieści do 255 znaków i możesz go użyć prawie wszędzie: w formułach, filtrach, raportach, widokach list, jako pole unikalne albo External ID, i można go indeksować. Obszar tekstowy (Text Area) też mieści 255, w osobnych wierszach, jak krótka notatka.

Powyżej 255: przechowywany przez odwołanie. Text Area (Long) (długi obszar tekstowy) mieści do 131 072 znaków, a Text Area (Rich) (obszar tekstu sformatowanego) tyle samo z formatowaniem, linkami i obrazami. Myślę o nich jak o czymś przechowywanym z boku, do czego rekord trzyma wskaźnik, i tak też się zachowują: brak indeksu, więc nie możesz uczynić ich unikalnymi ani External ID; nie możesz po nich filtrować w klauzuli SOQL WHERE (SOQL WHERE (opens in a new tab), po angielsku); formuły nie mogą ich używać (Formula Field Limits and Restrictions (opens in a new tab)); a raporty pokazują tylko pierwsze 254 znaki pola niestandardowego, przy czym filtry raportów przeszukują mniej więcej tylko pierwsze 255 (Filter Restrictions for Text Area (Long) Fields (opens in a new tab)). Obrazy wgrane do pola tekstu sformatowanego mogą mieć do 1 MB każdy i liczą się do miejsca na pliki, a tekst do miejsca na dane (Rich Text Area Field Considerations (opens in a new tab), po angielsku). Jeśli więc ktokolwiek musi wyszukiwać, sortować, dopasowywać albo raportować po tej wartości, trzymaj ją poniżej 255 i niech zostanie polem tekstowym.

Text (Encrypted) (tekst szyfrowany) przechowuje do 175 znaków w postaci zaszyfrowanej, przy użyciu Classic Encryption. Jeśli twój org używa Shield Platform Encryption, szyfrujesz zamiast tego zwykłe pole tekstowe, i w ten sposób da się zaszyfrować także wiele innych typów.

Daj każdemu polu opis

Mój standard: każde pole dostaje opis. Wierzę w to od dawna, a w czasach AI ma to większe znaczenie niż kiedykolwiek: każde narzędzie AI i każdy agent, który czyta twój org, czyta opisy, żeby zrozumieć, co pole znaczy. Pusty opis to zgadywanie, które tylko czeka, żeby się wydarzyć. Co znaczy Customer_Status__c? Kto jest jego właścicielem? Skąd pochodzi? Czy użytkownicy mogą je edytować, czy ERP nadpisze je dziś w nocy? Za pół roku nie będę pamiętał, a za trzy lata administrator utrzymujący org nie będzie wiedział, jeśli mu tego nie powiemy. Etykieta to nie dokumentacja, nazwa API też nie.

Na intensywnie współdzielonych obiektach (konto, kontakt, szansa sprzedaży) używam też prefiksów nazw dla pól specjalistycznych, żeby ich pochodzenie i cel było widać w samej nazwie: na przykład wszystko, czego właścicielem jest ERP, zaczyna się od tego samego prefiksu. Nie chodzi mi o dwunastowyrazowe nazwy API. Chcę, żeby model sam się objaśniał.

Klasyfikuj to, co ważne: pola taksonomii

Salesforce daje każdemu polu zestaw metadanych klasyfikacyjnych. Nazywam je polami taksonomii. Możesz zapisać właściciela danych (Data Owner); użycie pola (Field Usage: Active, DeprecateCandidate, Hidden); poziom wrażliwości danych (Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical); oraz kategoryzację zgodności (Compliance Categorization): PII, HIPAA, GDPR, PCI, CCPA i inne. Działają na polach standardowych i niestandardowych (Data Classification Metadata Fields (opens in a new tab), po angielsku).

Po co się trudzić? Bo procesy potrafią je czytać. Oznacz pole jako GDPR, a proces może znaleźć każde pole GDPR na rekordzie i je zamaskować albo usunąć. A gdy warstwa zaufania Salesforce wysyła prompt do dużego modelu językowego, może użyć dokładnie tej klasyfikacji do maskowania wrażliwych pól: w drodze tam zamienia nazwisko klientki, powiedzmy „Maria Lopez”, na symbol zastępczy, model nigdy nie widzi nazwiska, a w drodze powrotnej nazwisko jest wstawiane z powrotem do odpowiedzi (Einstein Trust Layer (opens in a new tab), po angielsku).

Aktualizacja. Salesforce dokumentuje teraz, że maskowanie dla LLM oparte na wzorcach i na polach jest wyłączone dla agentów: maskowanie może odebrać kontekst, którego agent potrzebuje do odpowiedzi (Data Masking Limitations in Agentforce (opens in a new tab), po angielsku). Klasyfikacja nadal steruje maskowaniem w innych funkcjach generatywnej AI, ale nie licz na nią, że utrzyma dane osobowe z dala od agenta; to decyzja o dostępie i projekcie (rozdział 12).

Moje stanowisko: klasyfikacja jest ważna w kluczowych momentach. Nie zamieniaj jej w trzy tygodnie wypełniania każdego okienka, bo tak kazał dział zarządzania. Używaj jej tam, gdzie ma znaczenie: dane osobowe, dane finansowe, dane regulowane i pola, dla których biznes potrzebuje nazwanego właściciela. Chodzi o to, żeby wrażliwość przestała być wiedzą w czyjejś głowie, a stała się częścią pola.

Poza egzaminem: co zmienia AI. Słaba dokumentacja pól kiedyś karała następnego administratora. Teraz wprowadza w błąd każde narzędzie AI i każdego agenta, który czyta schemat: czy Flag2__c jest wrażliwe, nadrzędne, wciąż używane? AI też tworzy pola szybciej niż jakikolwiek zespół, więc nazwy, opisy i klasyfikacja są częścią architektury, a nie porządków.

Każde pole to zobowiązanie

Kiedy pole już działa i zbiera dane, wszystko zaczyna się na nim opierać. Ekrany je pokazują, przepływy się na nim rozgałęziają, reguły sprawdzania poprawności je sprawdzają, raporty po nim grupują, integracje je wysyłają i czytają, a teraz rozumują o nim narzędzia AI. Każde z nich robi założenia o polu: o jego typie, długości, o tym, czy kiedykolwiek bywa puste, i o tym, co znaczą jego wartości. Zmień pole później, a najpierw musisz znaleźć każde z tych założeń. Zmiana nazwy wartości listy wyboru, skrócenie pola tekstowego albo zamiana pola tekstowego w listę wyboru brzmi jak drobna zmiana, a może zepsuć integrację w systemie innej firmy. Dlatego pole to zobowiązanie.

Click to enlarge

Nie chcę, żeby ten moduł zniechęcił cię do tworzenia pól. Salesforce jest zbudowany do rozszerzania; korzystaj z tego. Chcę, żeby pytanie zmieniło się z „jaki typ pola wybrać?” na „co znaczą te dane i jakie zachowanie obiecujemy?”. Typ, wymagane, unikalne, External ID, lista wyboru, formuła, opis, klasyfikacja: razem są fizycznym wyrazem modelu logicznego z rozdziału 2.

Co tu decyduje architekt

• Co znaczy wartość, zanim zostanie wybrany typ pola, i czy to atrybut, identyfikator, kontrolowane słownictwo, czy w rzeczywistości inna encja.
• Czy wartość to bieżące obliczenie, które można wyliczać, czy fakt historyczny, który trzeba przechowywać.
• Który system jest właścicielem każdego identyfikatora i czy jego unikalność to prawdziwa obietnica biznesu.
• Kiedy wymagana wartość jest naprawdę znana i co dzieje się z rekordami i integracjami, które jej nie mają.
• Jakiego opisu, nazewnictwa i klasyfikacji potrzebuje pole, żeby ludzie, procesy i AI mogli bezpiecznie z niego korzystać.

Do zgłębienia

• Pomoc Salesforce, Data Classification Metadata Fields (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Pomoc Salesforce, Einstein Trust Layer: Designed for Trust (opens in a new tab) i Data Masking Limitations in Agentforce (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Pomoc Salesforce, Picklist Limitations (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Pomoc Salesforce, Formula Field Limits and Restrictions (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.