Użytkownik widzi rekord, którego nie powinien — jak znaleźć przyczynę

Dlaczego ta osoba widzi ten rekord? to najczęstsze pytanie o dostęp w Salesforce — i najtrudniejsze do rozstrzygnięcia „na oko”, ponieważ platforma nigdy nie decyduje o widoczności w jednym miejscu. Przyznaje sumę kilku mechanizmów. Ten przewodnik daje Ci powtarzalną kolejność działań, by znaleźć ten jeden, który otworzył dostęp.

Najpierw model myślowy

Współdzielenie w Salesforce jest addytywne i wygrywa najbardziej liberalna reguła. Nie szukasz reguły, która zezwala na dostęp, oraz reguły, która go blokuje. Szukasz jakiegokolwiek pojedynczego przyznania, bo jedno wystarczy. (Pełną warstwowość opisujemy w kto może zobaczyć rekord w Salesforce.)

Jeśli choć jeden mechanizm przyznaje dostęp, użytkownik go ma. Twoim zadaniem jest znaleźć, który to.

Na rekordzie kliknij Sharing (dostępny dla obiektów, których org-wide default nie jest w pełni publiczny). Lista pokazuje użytkowników z dostępem oraz kolumnę Reason — Owner, Role Hierarchy, Sharing Rule, Manual Share, Team i tak dalej. W większości przypadków od razu wskazuje to winowajcę.

Jeśli użytkownika w ogóle nie ma na liście, a mimo to widzi rekord, podejrzewaj obejście na poziomie profilu — przejdź do Kroku 2.

Krok 2 — Wyklucz obejścia na poziomie uprawnień

Te całkowicie ignorują model współdzielenia:

View All Data / Modify All Data (uprawnienia systemowe, np. w profilu System Administrator).
View All / Modify All na poziomie tego konkretnego obiektu.

Jeśli użytkownik ma którekolwiek z nich przez profil lub permission set, zmiany w współdzieleniu nie ukryją rekordu. Musisz usunąć uprawnienie. Sprawdź jego profil oraz każdy przypisany permission set.

Krok 3 — Przejdź przez warstwy współdzielenia, od góry do dołu

Jeśli to faktycznie przyznanie przez współdzielenie, ustal, która warstwa za to odpowiada:

Org-wide default jest zbyt otwarty

Jeśli OWD obiektu to Public Read Only lub Public Read/Write, każdy z dostępem do obiektu widzi każdy rekord. Naprawa jest strukturalna — zaostrz org-wide default i świadomie przyznaj dostęp na nowo.

Hierarchia ról przekazuje dostęp w górę

Jeśli użytkownik stoi powyżej właściciela rekordu w hierarchii ról, a opcja „Grant Access Using Hierarchies” jest włączona, automatycznie dziedziczy dostęp właściciela. To najczęstsza niespodzianka.

Zbyt szeroka reguła współdzielenia

Reguła oparta na kryteriach, taka jak Region = EMEA → udostępnij roli X, może obejmować znacznie więcej osób niż zamierzano, zwłaszcza po zmianach danych lub ról. Przejrzyj reguły wskazujące na rolę użytkownika, grupy publiczne lub terytorium.

Udostępnienie ręczne lub niejawne

Udostępnienie ręczne (manual share): ktoś użył przycisku Share na rekordzie.
Udostępnienie niejawne (implicit share): dostęp do nadrzędnego Account przyznaje ograniczony dostęp do odczytu powiązanych spraw (Cases) i kontaktów (Contacts). O tym ludzie nieustannie zapominają — i zawsze jest to tylko odczyt.
Apex managed sharing: udostępnienie utworzył niestandardowy kod; przycisk Sharing je pokazuje, ale źródło jest w kodzie.

Zespoły i terytoria

Członkostwo w zespole (Account/Opportunity/Case) lub pasujące terytorium w ramach Enterprise Territory Management — każde z nich przyznaje dostęp niezależnie.

Krok 4 — Upewnij się, że to nie opóźnienie przeliczania

Jeśli dostęp wygląda niespójnie, być może obserwujesz kończące się przeliczanie współdzielenia (sharing recalculation) po niedawnej zmianie własności, roli lub reguły. Zaczekaj na jego zakończenie, zanim ogłosisz błąd.

Lista kontrolna diagnozy

Przycisk Sharing → odczytaj Reason dla danego użytkownika.
Profil + permission sety → jakiekolwiek View All / Modify All?
OWD zbyt otwarty dla tego obiektu?
Użytkownik powyżej właściciela w hierarchii ról?
Jakaś reguła współdzielenia (zwłaszcza oparta na kryteriach) obejmująca go?
Udostępnienie ręczne, niejawne lub przez Apex?
Członek zespołu lub pasujące terytorium?
Niedawna zmiana → poczekaj na przeliczanie.

Pierwsze „tak” jest Twoją odpowiedzią — a tę samą widoczność może przyznawać więcej niż jedna ścieżka. W przypadku odwrotnego problemu — gdy użytkownik nie widzi rekordu, który powinien — zajrzyj do listy kontrolnej diagnozy brakującego dostępu.

Jak zrobić to w sekundy zamiast w całe popołudnie

Przechodzenie przez osiem warstw dla każdej pary użytkownik–rekord, przez profile, permission sety i sześć mechanizmów współdzielenia, to dokładnie ta ręczna mozolna praca, która ukrywa realne luki w dostępie. AgentForceAccess robi to za Ciebie: zapytaj zwykłym językiem, dlaczego użytkownik widzi rekord, a narzędzie prześledzi każdą warstwę i wskaże dokładne przyznanie — żebyś od razu przeszedł do naprawy.

Najczęściej zadawane pytania

Jaka jest najszybsza pierwsza kontrola?

Otwórz rekord, kliknij przycisk Sharing i odczytaj kolumnę „Reason” dla danego użytkownika. Dla większości standardowych obiektów wskazuje ona mechanizm przyznający dostęp — Owner, Role Hierarchy, Sharing Rule, Manual i tak dalej. Sprawdź też, czy użytkownik po prostu nie ma uprawnienia „View All Data” lub „View All” na poziomie obiektu.

Przycisk Sharing pokazuje „Role Hierarchy” — co teraz?

Ktoś, nad kim użytkownik stoi w hierarchii ról, jest właścicielem rekordu (lub rekord jest z nim współdzielony), a dla danego obiektu włączono opcję „Grant Access Using Hierarchies”. Aby usunąć ten dostęp, należałoby zmienić hierarchię, własność rekordu albo wyłączyć dostęp przez hierarchię dla obiektów niestandardowych — żadnej z tych decyzji nie podejmuj pochopnie.

Czy przyczyną może być uprawnienie profilu, a nie współdzielenie?

Tak. „View All Data”/„Modify All Data” oraz „View All”/„Modify All” na poziomie obiektu całkowicie pomijają model współdzielenia. Jeśli użytkownik ma którekolwiek z nich, żadna zmiana w współdzieleniu nie ukryje rekordu — zamiast tego musisz usunąć uprawnienie.

Dlaczego dostęp pojawia się i znika z przerwami?

To przeliczanie współdzielenia (sharing recalculation). Po zmianach własności, przeniesieniach ról lub edycji reguł Salesforce przetwarza udostępnienia asynchronicznie. W tym czasie dostęp może wyglądać niespójnie. Zaczekaj na zakończenie przeliczania, zanim uznasz, że to błąd konfiguracji.