Własność i cykl życia

🌐 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ł 8 z 10 w rozdziale Architektura danych Salesforce, rozdziale 3 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Relacje mają konsekwencje · Dalej: Spójność danych

Pytanie, na które odpowiada ten moduł: kto jest właścicielem rekordu i co dzieje się z nim przez całe jego życie?

Kiedy patrzę na model danych, nie chcę wiedzieć tylko, czym są obiekty i jak się łączą. Chcę wiedzieć, co dzieje się z rekordami w czasie. Kto je tworzy? Kto jest ich właścicielem? Kto może je przypisać komuś innemu? Co się dzieje, gdy zmienia się relacja biznesowa, gdy przestają być aktywne? Czy kiedykolwiek powinny zostać usunięte i jak długo je przechowujemy? Nic z tego nie widać na diagramie ERD, czyli diagramie związków encji: prostokątach i liniach modelu danych z rozdziału 2. Wszystko to jest architekturą danych. A w Salesforce własność to miejsce, w którym model danych i model bezpieczeństwa wpadają na siebie.

Własność to więcej niż nazwisko w polu

Administratorzy widzą na rekordzie pole Właściciel i czytają je jak etykietę: Bart jest właścicielem tego konta, Lisa tego zgłoszenia. Może to znaczyć właśnie to. Ale w Salesforce własność jest też mechanizmem platformy. Na obiektach, które mają właściciela, właściciel decyduje o tym, kto może widzieć rekord, przez hierarchię ról, reguły udostępniania, kolejki i ponowne przypisanie. Kiedy więc pytam „kto jest właścicielem tego rekordu?”, nie pytam, czyje nazwisko pojawi się na stronie. Pytam, jakie zachowanie bezpieczeństwa i cyklu życia do niego przypinamy. Właścicielem może być użytkownik albo, w przypadku niektórych obiektów, między innymi obiektów niestandardowych, zgłoszeń i potencjalnych klientów, kolejka, i tak czy inaczej właściciel dostaje pełny dostęp do rekordu (Understanding Sharing (opens in a new tab), po angielsku).

Dlatego oddzielam odpowiedzialność biznesową od własności rekordu. Czasem to ta sama osoba. Czasem nie. Jeśli biznes mówi, że za dostawę odpowiada dyspozytor, nie czyni to automatycznie dyspozytora właścicielem. Odpowiedzialność może mieszkać we własnym polu, a własność może być ustawiona tak, żeby wspierać bezpieczeństwo i skalę. Nie pozwól, żeby te dwie rzeczy się pomieszały tylko dlatego, że obie po angielsku nazywają się „owner”.

Tabela udostępniania: gdzie własność staje się dostępem

Niektórzy nawet nie wiedzą, czym jest tabela udostępniania. Każdy architekt danych powinien.

Większość udostępnień rekordu jest przechowywana w powiązanym obiekcie udostępniania (share object), czyli wersji listy kontroli dostępu w wydaniu Salesforce (Understanding Sharing (opens in a new tab), po angielsku). Konto ma AccountShare, kontakt ma ContactShare, a obiekt niestandardowy dostaje własny: Truck__c ma Truck__Share (Sharing a Record Using Apex (opens in a new tab), po angielsku). Każdy wiersz mówi cztery rzeczy:

• Który rekord: identyfikator rodzica (parent ID).
• Komu: użytkownikowi albo grupie (grupie publicznej, grupie roli, terytorium).
• Ile: Read, Edit albo All (pełny dostęp).
• Dlaczego: przyczyna wiersza (row cause). Owner dla właściciela, Rule dla reguły udostępniania, Manual dla udostępnienia ręcznego, Team, przyczyny niejawne, które Salesforce dodaje między kontem a jego rekordami podrzędnymi, oraz przyczyny, które programista definiuje dla udostępniania Apex.

Na zajęciach otwieram Workbench i odpytuję tabelę udostępniania, udostępniając rekord, a ty patrzysz, jak wiersze pojawiają się i znikają. Gdy ktoś pyta „dlaczego ta osoba to widzi?”, odpowiedź często siedzi w wierszu, razem z przyczyną.

Ale nie wszystko w niej jest. Ustawienie domyślne dla całej organizacji (organization-wide default) nie jest wierszem. Hierarchia ról też nie jest tam przechowywana: dostęp dla osób nad właścicielem jest wyliczany wtedy, gdy jest potrzebny. A View All, Modify All, View All Data i Modify All Data całkowicie pomijają tabelę udostępniania (Sharing a Record Using Apex (opens in a new tab), po angielsku). Jak mówię na zajęciach: zaznacz View All, a ominąłeś tabelę udostępniania.

Salesforce udostępnia też niektóre rekordy za ciebie, ze względu na to, jak są powiązane. To udostępnianie niejawne (implicit sharing) i działa między kontem a jego rekordami podrzędnymi. Jeśli widzisz kontakt, zgłoszenie albo szansę sprzedaży, możesz też czytać konto, do którego należą. A właściciel konta dostaje dostęp do kontaktów, zgłoszeń i szans sprzedaży tego konta, na poziomie ustawionym przez rolę właściciela (Implicit Sharing (opens in a new tab), po angielsku). W ostatnich wydaniach Salesforce wylicza część tego dostępu do rekordów podrzędnych wtedy, gdy jest potrzebny, zamiast przechowywać go jako wiersze, więc nie zdziw się, gdy zapytanie do tabeli udostępniania go nie pokaże. Daję ci tu tylko wskazówkę; szczegóły są w rozdziale Relacje i wbudowane udostępnianie.

Jeszcze jeden wyjątek, na wypadek gdy masz wielu użytkowników zewnętrznych. Użytkownicy społeczności o dużym wolumenie (high-volume community users), czyli licencje Customer Community stworzone dla tysięcy, a nawet milionów klientów, nie mają roli, nie mogą należeć do grup publicznych i nie można im dawać rekordów przez reguły udostępniania ani udostępnienia ręczne (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab), po angielsku). Dla nich tabela udostępniania nie jest odpowiedzią: docierają do rekordów przez zestawy udostępniania (sharing sets), które dopasowują konto lub kontakt rekordu do konta lub kontaktu samego użytkownika. To jeden z powodów, dla których te licencje się skalują. Kurs Sharing and Visibility omawia to w rozdziale Udostępnianie użytkownikom zewnętrznym.

I pamiętaj moduł 7: obiekt szczegółowy w ogóle nie ma obiektu udostępniania. Jego dostęp pochodzi z obiektu udostępniania rekordu nadrzędnego i z Sharing Setting w polu master-detail.

Dlaczego obchodzi to architekta danych? Bo własność jest zapisana w tej tabeli. Każda zmiana właściciela, każda nowa reguła udostępniania, każde przejście użytkownika do innej roli albo grupy oznacza, że Salesforce dodaje i usuwa wiersze. Przy kilku tysiącach rekordów nikt tego nie zauważa. Przy dziesięciu milionach, gdy jeden użytkownik jest właścicielem większości z nich, to przeliczanie, które zaraz poznamy.

Wiedza egzaminacyjna. Obiekt udostępniania obiektu niestandardowego nazywa się Object__Share, na przykład Truck__Share. Obiekt szczegółowy nie ma obiektu udostępniania: jego dostęp pochodzi od rekordu nadrzędnego. A gdy zmienia się właściciel rekordu, jego udostępnienia ręczne są usuwane, podczas gdy udostępnianie Apex z własną przyczyną programisty zostaje.

Tu model danych przekazuje pałeczkę modelowi bezpieczeństwa, a resztę uczę w kursie Sharing and Visibility Architect: 22 sposoby Steve’a na udostępnienie rekordu, Ustawienia domyślne dla całej organizacji, własność, kolejki i hierarchia ról, Relacje i wbudowane udostępnianie o udostępnieniach niejawnych oraz Udostępnianie programowe i bezpieczny kod o przyczynach udostępniania Apex. W tym kursie rozdział 12 zbiera to wszystko dla ludzi, aplikacji i agentów.

Czasem własność jest dziedziczona

W poprzednim module widzieliśmy, że rekord podrzędny w relacji master-detail nie ma własnego właściciela; podąża za rodzicem. Często to dokładnie właściwe. Czy biznes potrzebuje innego właściciela dla każdej pozycji dostawy? Nie. Dostawa jest właścicielem cyklu życia, a pozycja do niej należy. Dlatego projekt relacji i projekt własności idą w parze: wybierając master-detail, podjęto już część decyzji o własności.

Kto jest właścicielem rekordów tworzonych przez systemy?

Teraz robi się ciekawie. Osoba tworzy konto i może zostać jego właścicielem. Ale ERP przysyła w nocy 100 000 transakcji. Kto jest ich właścicielem? Użytkownik integracyjny? Kolejka? Regionalny właściciel wyliczony z danych? Konto systemowe, o którym nikt nie myślał od pięciu lat? A teraz rekordy tworzą też agenci.

Moje stanowisko: to zależy od tego, czy własność ma znaczenie dla udostępniania. Użytkownik integracyjny albo użytkownik agenta to prawidłowy użytkownik i może być właścicielem rekordów. Jeśli własność decyduje o dostępie w danym obiekcie (przez hierarchię ról albo reguły udostępniania), przypisz rekordy właściwemu właścicielowi: prawdziwemu użytkownikowi, kolejce albo dedykowanemu użytkownikowi-właścicielowi. Jeśli nie decyduje, pozostawienie użytkownika systemowego jako właściciela może być lepszym wyborem, bo wtedy ścieżka audytu prowadzi prosto do tego, co utworzyło rekord.

Tak czy inaczej, zdecyduj o tym świadomie. Konto integracyjne, które jest właścicielem wszystkiego, po cichu stało się częścią twojej architektury bezpieczeństwa, a ktoś musi wiedzieć, co się stanie, jeśli kiedykolwiek zostanie dezaktywowane.

Własność może stać się problemem skali

Rozkład też ma znaczenie. Dziesięć milionów rekordów rozłożonych na tysiące właścicieli to jeden kształt. Dziesięć milionów rekordów jednego użytkownika to zupełnie inny. Salesforce nazywa to nierównomiernym rozkładem własności (ownership data skew), gdy jeden użytkownik jest właścicielem ponad 10 000 rekordów obiektu (Ownership Data Skew (opens in a new tab), po angielsku). Zwykle dzieje się tak, gdy ktoś parkuje wszystko na jednym użytkowniku albo kolejce: wszystkie nieprzypisane leady na użytkowniku-zaślepce, każdy rekord integracji na użytkowniku integracyjnym. To nieszkodliwe, dopóki ten użytkownik nie przesunie się w hierarchii ról albo nie wejdzie do grupy, od której zależy reguła udostępniania, czy z niej nie wyjdzie. Wtedy Salesforce musi poprawić ogromną liczbę wpisów udostępniania i dostajesz długotrwałe przeliczenia.

Zalecenia są praktyczne. Rozkładaj własność na więcej użytkowników, gdzie się da. Jeśli jeden użytkownik musi być właścicielem wielu rekordów, trzymaj go poza hierarchią ról; jeśli potrzebuje roli, daj mu własną rolę na samej górze i go nie przesuwaj, a także trzymaj go poza grupami publicznymi używanymi przez reguły udostępniania (Ownership Data Skew (opens in a new tab), po angielsku). To samo myślenie dotyczy rodzica ze zbyt wieloma dziećmi z poprzedniego modułu, czyli nierównomiernego rozkładu rodzic-dziecko.

Rozkład jest więc częścią modelu fizycznego. Nie pytaj tylko, ile jest rekordów; pytaj, jak są rozłożone. To kolejna wersja Liczby Zer: nie tylko ile zer, ale gdzie się skupiają. Część 2 wchodzi głęboko w nierównomierny rozkład; tu chcę, żeby udało ci się go dostrzec z daleka. Kurs Sharing and Visibility wraca do tego w rozdziale Udostępnianie w dużej skali.

„Domyślny właściciel” staje się architekturą

Oto wzorzec, który widzę bez przerwy. Nikt nie wie, kto powinien być właścicielem, więc ktoś mówi: „Po prostu przypisz wszystko użytkownikowi integracyjnemu” albo „utwórz ogólnego użytkownika o nazwie System”. Może to właściwe. Ale nie rób tego przypadkiem. Tymczasowe ustawienie domyślne ma zwyczaj stawać się trwałe: dwa lata później każdy rekord należy do integration@company.com, nikt nie pamięta dlaczego, a zmiana tego to projekt. To Test Odwracalności z rozdziału 1: zanim dasz milion rekordów jednemu właścicielowi, zapytaj, ile będzie kosztować późniejsza zmiana.

Ponowne przypisanie to zdarzenie w cyklu życia

Właściciele się zmieniają. Handlowcy odchodzą, terytoria się przesuwają, zespoły się reorganizują, regiony są ponownie równoważone. Co zależy od właściciela: udostępnianie, automatyzacja, raporty, kolejki, eskalacje, integracje? Jeśli zmiana właściciela zmienia to, kto może widzieć rekord, ponowne przypisanie to nie sprzątanie administracyjne. To zdarzenie bezpieczeństwa, a przy milionie rekordów także operacyjne. Obserwuj wtedy tabelę udostępniania: udostępnienia ręczne są usuwane, gdy zmienia się właściciel, a udostępnianie Apex z własną przyczyną programisty przetrwa tę zmianę (Understanding Sharing (opens in a new tab), po angielsku). Na zajęciach udostępniam komuś rekord, zmieniam właściciela, a ta osoba traci dostęp. Sala zawsze jest zaskoczona.

I pamiętaj, że własność to nie to samo co dostęp. Właściciel nie jest jedyną osobą, która musi widzieć rekord, a Salesforce ma wiele sposobów nadawania dostępu: hierarchię ról, reguły udostępniania, zespoły, terytoria, udostępnianie ręczne i programowe. Kurs Sharing and Visibility wchodzi w nie głęboko, zaczynając od rozdziału 22 sposoby Steve’a na udostępnienie rekordu. Uwaga architekta jest prostsza: nie używaj własności do rozwiązywania każdego problemu z dostępem. Jeśli przestawiasz właścicieli tylko po to, żeby ktoś mógł zobaczyć rekord, pewnie rozwiązujesz zły problem.

Utworzenie to dopiero początek

Wiele modelowania danych kończy się na utworzeniu: pola, obiekt, relacja, gotowe. Ale rekord może żyć dziesięć lat. Jest aktualizowany, zmienia właścicieli, status i relacje, staje się nieaktywny, staje się historią, może wymagać archiwizacji, a kiedyś może usunięcia. Architektura to nie tylko to, jak rekord się rodzi. To, co dzieje się od narodzin do śmierci.

Click to enlarge

Nie usuwaj tylko dlatego, że coś jest stare

Partner detaliczny przestaje przysyłać pracę. Usunąć konto? Nie automatycznie: jego dostawy, reklamacje i historia rozliczeń nadal mają znaczenie. Ciężarówka zostaje wycofana. Usunąć ją razem z historią dostaw i reklamacjami szkód? Rzecz może nie być już aktywna, ale jej dane nadal są. Oddzielam więc nieaktywne od nieistniejącego. Wycofana ciężarówka może zostać w modelu; były pracownik może nadal pojawiać się w historii audytu. Architektura musi zachować fakty, które mają znaczenie po zakończeniu relacji operacyjnej.

Retencja to wymaganie biznesowe

Druga strona: trzymanie wszystkiego na zawsze też nie jest architekturą. Przestrzeń rośnie, raporty zwalniają, wyszukiwanie robi się bardziej zaszumione, a prawo o prywatności może mówić, że część danych musi zniknąć. Chcę więc wyraźnej odpowiedzi na pytanie: jak długo to przechowujemy? „Salesforce to przechowuje” to nie polityka retencji.

I przeważnie to pytanie dotyczy danych transakcyjnych. Dane referencyjne, czyli produkty, typy usług, centra dystrybucyjne, nie rosną ogromnie, a inne rekordy na nie wskazują, więc zwykle zostają. Dane klientów są pośrodku: może przyjść dzień, w którym zakończysz życie klienta w systemie, zwłaszcza gdy przechowujesz dane osobowe, a powód ich przechowywania wygasa. Ale wolumen jest w transakcjach: dostawach, zamówieniach, zgłoszeniach, wizytach, tworzonych codziennie, bez końca. To one rosną do setek milionów wierszy i to tam retencja musi być wyraźna: może dwa lata danych operacyjnych w orgu, siedem lat dokumentów finansowych gdzieś indziej, dziewięćdziesiąt dni dla części zdjęć. To reguły biznesowe, a jeśli nikt o nie nie zapytał, powinien to zrobić architekt.

Powtarzam to na zajęciach od lat: jeśli nie archiwizujesz dziś, czy kiedykolwiek będziesz archiwizować? „Zajmiemy się tym później” ma zwyczaj zamieniać się w awaryjny projekt przy trzystu milionach rekordów. Część 2 ma cały moduł o archiwizacji i usuwaniu danych, zbudowany na tym samym pytaniu.

Steve Trucking: kto jest właścicielem dostawy?

Dostawa jest tworzona z manifestu partnera detalicznego przez integrację, około 3300 razy dziennie. Kto jest jej właścicielem? Nie partner detaliczny; to relacja biznesowa. Nie odbiorca. Ekipa ją realizuje, ale czy rekord powinien zmieniać właściciela za każdym razem, gdy ekipy zamieniają się ciężarówkami? Dyspozytor? Centrum dystrybucyjne? Kolejka? Użytkownik integracyjny, który ją utworzył?

Teraz zastosuj ten moduł, zaczynając od pytania, które o tym rozstrzyga: czy własność decyduje o czyimkolwiek dostępie do dostaw? W Steve Trucking nie. Dyspozytorzy widzą dostawy swojego centrum dystrybucyjnego, ekipy widzą te na swoich trasach, a każdy detalista widzi własne w portalu partnerów. Nic z tego nie zależy od tego, kto jest właścicielem rekordu; wynika z centrum dystrybucyjnego, trasy i partnera.

Moja odpowiedź brzmi więc: właścicielem dostaw jest użytkownik integracyjny. To dobry przykład użytkownika systemowego, który celowo jest właścicielem rekordów:

• Ślad audytowy jest uczciwy. Właściciel każdej dostawy mówi, skąd ona przyszła: z integracji manifestów.
• Dostęp wynika z udostępniania, nie z własności. Reguły udostępniania oparte na kryteriach, ustawione na centrum dystrybucyjne, dają zespołowi każdego CD jego dostawy; partnerzy docierają do swoich przez portal.
• Nierównomierny rozkład jest wyeliminowany w projekcie. Przy 3300 dziennie użytkownik integracyjny przekracza 10 000 dostaw w trzy dni, więc od pierwszego dnia mamy nierównomierny rozkład własności, i to w porządku, jeśli to zaplanujemy. Użytkownik integracyjny nie ma roli, więc nic nad nim w hierarchii nie musi być przeliczane, i trzymamy go poza grupami publicznymi, których używają nasze reguły udostępniania.
• Nikt nie przypisuje dostaw ponownie. Ekipy zamieniają się ciężarówkami, dyspozytorzy zmieniają się na zmianach, a właściciel nigdy się nie zmienia, więc nie ma burzy ponownych przypisań i nie ma udostępnień ręcznych do stracenia.

I zapisz, co się stanie, jeśli ten użytkownik kiedykolwiek zostanie dezaktywowany albo zastąpiony, bo teraz jest właścicielem milionów rekordów. To decyzja, którą następny zespół będzie musiał znaleźć.

Poza egzaminem: co zmienia AI. Agenci tworzą i zmieniają rekordy w tempie maszyn. Jeśli agent utworzy 100 000 rekordów na własnym użytkowniku, „poprawimy właściciela później” staje się nierównomiernym rozkładem, przeliczaniem udostępniania i projektem sprzątania. Ustal regułę własności dla agenta, zanim ruszy, tym samym pytaniem: czy własność ma tu znaczenie dla udostępniania?

Co tu decyduje architekt

• Czy własność odwzorowuje odpowiedzialność biznesową, mechanizm bezpieczeństwa, czy jedno i drugie, i gdzie mieszka odpowiedzialność, jeśli nie w polu Właściciel.
• Czy rekordy potrzebują własnego właściciela, czy powinny dziedziczyć go po rodzicu.
• Kto jest właścicielem rekordów tworzonych przez integracje i agentów, zależnie od tego, czy własność decyduje o udostępnianiu.
• Jak rozkłada się własność i jak uniknąć nierównomiernego rozkładu własności, gdy jeden użytkownik musi być właścicielem wielu rekordów.
• Kiedy rekordy stają się nieaktywne, kiedy są archiwizowane, jak długo się je przechowuje i kiedy usunięcie jest właściwe.

Patrząc na model fizyczny, nie pytaj tylko, gdzie przechowywane są dane. Pytaj, kto jest ich właścicielem dziś, kto może nim być jutro i co się stanie, gdy przestaniemy ich potrzebować. Dalej: nawet z właściwym obiektem, polami, relacjami i właścicielem dane wciąż muszą pozostać wiarygodne.

Do zgłębienia

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: właściciele (użytkownik albo kolejka dla obiektów niestandardowych, zgłoszeń i potencjalnych klientów) dostają pełny dostęp; większość udostępnień mieszka w powiązanym obiekcie udostępniania; hierarchia ról jest wyliczana w czasie działania; udostępnienia ręczne są usuwane przy zmianie właściciela, zarządzane udostępnianie Apex zostaje; wartości przyczyn wierszy.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: AccountShare, MyCustomObject__Share; obiekty szczegółowe nie mają obiektu udostępniania; czego obiekt udostępniania nie śledzi (OWD, hierarchia ról, View All i Modify All).
• Pomoc Salesforce, Implicit Sharing (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: dostęp między kontem a jego kontaktami, zgłoszeniami i szansami sprzedaży.
• Pomoc Salesforce, About High-Volume Community or Site Users (opens in a new tab) i Sharing Rule Considerations (opens in a new tab) (po angielsku), sprawdzono 2026-10-13: brak ról, brak reguł udostępniania i udostępnień ręcznych; zamiast nich zestawy udostępniania.
• Kurs Sharing and Visibility Architect: 22 sposoby Steve’a na udostępnienie rekordu, Ustawienia domyślne dla całej organizacji, własność, kolejki i hierarchia ról, Relacje i wbudowane udostępnianie, Udostępnianie programowe i bezpieczny kod, Udostępnianie użytkownikom zewnętrznym, Udostępnianie w dużej skali.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) i Parent-Child Data Skew (opens in a new tab) (po angielsku), sprawdzono 2026-10-02.