Sharing rules a hierarchia ról w Salesforce: jaka jest różnica

Hierarchia ról i sharing rules to dwa mechanizmy, po które administratorzy sięgają najczęściej — i dwa najczęściej mylone ze sobą. Oba poszerzają dostęp do rekordów, ale w różnych kierunkach i z różnych powodów. Właściwe uchwycenie tej różnicy decyduje o tym, czy masz czysty model współdzielenia, czy plątaninę nakładających się reguł.

Różnica w jednym zdaniu

Hierarchia ról — nadaje dostęp automatycznie i pionowo: każdy stojący w strukturze organizacyjnej powyżej właściciela rekordu dziedziczy jego dostęp.
Sharing rules — nadają dostęp świadomie i poziomo: współpracownikom, innym zespołom lub grupom, których hierarchia nigdy by nie połączyła, na podstawie właściciela lub kryteriów pól.

Obie działają na bazie organization-wide default i mogą jedynie otwierać dostęp, nigdy go ograniczać. (Pełną warstwowość pokazujemy w kto może zobaczyć rekord.)

Hierarchia ról: dostęp wędruje w górę

Gdy dla danego obiektu włączona jest opcja Grant Access Using Hierarchies, menedżerowie automatycznie dziedziczą dostęp do rekordów należących do użytkowników stojących niżej — lub udostępnionych tym użytkownikom. Bez żadnej reguły, bez konfiguracji per rekord.

Przykład. Organization-wide default Private dla Opportunities. Przedstawiciel handlowy jest właścicielem szansy sprzedaży. Jego menedżer oraz VP tego menedżera widzą ją automatycznie, ponieważ stoją w hierarchii powyżej przedstawiciela. To hierarchia ról wykonująca swoją pracę.

To rozwiązanie idealne do wglądu typu menedżer widzi zespół — i zarazem najczęstsze źródło niespodzianek w stylu „dlaczego oni to widzą?”, bo nikt nie konfigurował tego per rekord.

Sharing rules rozszerzają dostęp w poprzek hierarchii, do użytkowników rozdzielonych przez strukturę organizacyjną. Występują w dwóch odmianach:

Oparte na właścicielu (ownership-based) — udostępniają rekordy należące do jednej grupy (roli, grupy publicznej, terytorium) innej grupie.
Oparte na kryteriach (criteria-based) — udostępniają rekordy, które pasują do wartości pól (np. Region = EMEA), grupie, roli lub terytorium.

Przykład. Sprzedaż EMEA i APAC to osobne gałęzie hierarchii, więc żadna z nich nie widzi szans drugiej. Reguła criteria-based — Region = EMEA → udostępnij Read grupie APAC Leadership — otwiera dokładnie ten dostęp między gałęziami, bez ingerencji w hierarchię.

Kiedy użyć której

Potrzeba	Użyj
Menedżerowie widzą rekordy swojego zespołu	Hierarchia ról
Dostęp podąża automatycznie za liniami raportowania	Hierarchia ról
Dwa równorzędne zespoły muszą widzieć swoje rekordy	Sharing rule (ownership-based)
Udostępnienie rekordów pasujących do kryteriów pól (region, typ, etap)	Sharing rule (criteria-based)
Udostępnienie grupie publicznej lub terytorium	Sharing rule
Jednorazowy dostęp do pojedynczego rekordu	Manual share (żadna z tych dwóch)

Kumulują się — i tu kryje się pułapka

Ponieważ dostęp jest addytywny i wygrywa najszersze uprawnienie, hierarchia ról i sharing rules łączą się ze sobą. Użytkownik może uzyskać dostęp do jednego rekordu jednocześnie przez hierarchię oraz przez dwie sharing rules. Żadna z nich nie nadpisuje pozostałych; każda pojedyncza wystarcza.

To także powód, dla którego wkrada się zbyt szerokie udostępnianie: każda reguła z osobna wygląda rozsądnie, ale to suma hierarchii + reguł + manual shares stanowi to, co użytkownik faktycznie widzi — a nikt nie trzyma całego tego obrazu w głowie.

Żadna z nich nie ogranicza — z założenia

Jeśli potrzebujesz zmniejszyć dostęp, sharing rules ani hierarchia ról nie pomogą. Zaostrz organization-wide default albo użyj restriction rules. Dodanie kolejnej sharing rule może jedynie otworzyć więcej dostępu.

Zobaczyć efekt łączny

Trudność nie tkwi w żadnym z mechanizmów z osobna — tkwi w ich sumie. Aby wiedzieć, dlaczego użytkownik widzi rekord, musisz ocenić hierarchię oraz każdą obowiązującą sharing rule oraz manual shares jednocześnie.

AgentForceAccess wylicza tę sumę za Ciebie: zapytaj, dlaczego użytkownik widzi rekord, a otrzymasz odpowiedź, czy odpowiada za to hierarchia ról, konkretna sharing rule, czy obie — prostym językiem, ze wskazaniem mechanizmu.

Najczęściej zadawane pytania

Jaka jest sedno różnicy w jednym zdaniu?

Hierarchia ról otwiera dostęp w górę i automatycznie wzdłuż linii raportowania, natomiast sharing rules otwierają dostęp w bok i celowo — dla użytkowników, których hierarchia nigdy by ze sobą nie połączyła.

Jeśli obie mogłyby nadać dostęp do tego samego rekordu, która wygrywa?

To nie ma znaczenia — dostęp w Salesforce jest addytywny i wygrywa najszersze uprawnienie. Jeśli dostęp nadaje albo hierarchia ról, albo sharing rule, użytkownik go ma. Nigdy nie potrzebujesz, by obie się „zgodziły”.

Czy sharing rule może odebrać dostęp?

Nie. Sharing rules i hierarchia ról mogą jedynie rozszerzać dostęp ponad organization-wide default. Aby ograniczyć dostęp, zmieniasz organization-wide default albo używasz restriction rules — nie sharing rules.

Czy nadal potrzebuję sharing rules, jeśli moja hierarchia ról jest dobrze zbudowana?

Zwykle tak. Hierarchia wyraża jedynie dostęp pionowy, menedżera nad podwładnym. W momencie gdy dwa równorzędne zespoły lub rola z innej gałęzi muszą widzieć swoje rekordy, tylko sharing rule potrafi to wyrazić.