Profile a permission sets i sharing rules w Salesforce

„Profile vs permission sets vs sharing rules” sprawia ludziom kłopot, bo te trzy elementy nie są alternatywami — odpowiadają na różne pytania i działają razem. Profile i permission sets decydują, co możesz zrobić z obiektem; sharing rules decydują, których rekordów to dotyczy. Oto jak się łączą.

Model dwóch sprawdzeń

Każdy dostęp do rekordu w Salesforce przechodzi przez dwa niezależne sprawdzenia:

1. Sprawdzenie obiektu i pól — z profili i permission sets: czy użytkownik ma CRUD na obiekcie oraz field-level security na polach?
2. Sprawdzenie rekordu — z modelu współdzielenia: czy org-wide defaults, hierarchia ról lub sharing rule przyznaje ten konkretny rekord?

Uprawnienie do obiektu jest bramą. Sharing decyduje, które rekordy przez nią przejdą. Oba muszą się powieść.

To fundament całego modelu dostępu do rekordów.

Profile i permission sets: „co możesz zrobić”

Sterują dostępem na poziomie obiektu i nie tylko:

• CRUD dla każdego obiektu (Read / Create / Edit / Delete).
• Field-level security — które pola są widoczne/edytowalne.
• Uprawnienia systemowe, widoczność aplikacji i zakładek oraz omijające dostęp View All / Modify All.

Profil a permission set

• Użytkownik ma dokładnie jeden profil — historycznie bazę uprawnień.
• Użytkownik może mieć wiele permission sets (oraz permission set groups) nałożonych na wierzch.

Nowoczesne, rekomendowane podejście jest oparte na permission sets: utrzymuj profil minimalnym i przyznawaj dostęp przez permission sets, ponieważ łatwiej je przypisywać, ponownie wykorzystywać i audytować niż rozrastającą się masę profili. (Role z kolei napędzają hierarchię sharingu — to odrębna oś od profili.)

Sharing rules: „które rekordy”

Sharing rules w ogóle nie dotykają dostępu do obiektu ani pól. Jedynie rozszerzają dostęp na poziomie rekordu — na podstawie własności lub kryteriów — ponad org-wide default. To, jak odnoszą się do hierarchii, opisuje sharing rules a hierarchia ról.

Co kluczowe: sharing rule nie uratuje brakującego uprawnienia do obiektu. Brak Read na Opportunities oznacza brak szans sprzedaży, niezależnie od tego, ile sharing rules wskazuje na danego użytkownika.

Gdzie uprawnienia nadpisują sharing

Jest jedno miejsce, w którym warstwy się przecinają: View All i Modify All (na poziomie obiektu) oraz View All Data / Modify All Data (w skali całej organizacji). Te całkowicie omijają model współdzielenia — użytkownik, który je posiada, widzi każdy rekord niezależnie od OWD, hierarchii czy reguł. Ponieważ są tak potężne, to pierwsza rzecz do sprawdzenia, gdy dostęp wygląda nieprawidłowo. Zobacz View All / Modify All — obejście, na które trzeba uważać.

Składając to w całość

Pytanie	Odpowiada
Czy użytkownik może w ogóle otworzyć ten obiekt?	Profil / permission set (CRUD)
Czy może zobaczyć to pole?	Field-level security
Które rekordy obiektu może zobaczyć?	Model współdzielenia
Czy może ominąć sharing?	View All / Modify All

Aby zrozumieć, dlaczego użytkownik może lub nie może dotrzeć do rekordu, czytasz obie osie razem — uprawnienia do obiektu/pól oraz sharing, który dotyczy tego rekordu.

Odczytywanie obu osi naraz

Trudność polega na tym, że żyją one w różnych częściach konfiguracji — profile i permission sets w jednym miejscu, model współdzielenia w drugim — i trzeba je w głowie przeciąć. AgentForceAccess wykonuje to przecięcie za Ciebie: zapytaj, co użytkownik może zrobić z rekordem, a uwzględni uprawnienia do obiektu, field-level security oraz model współdzielenia razem, cytując dokładnie to, co przyznaje lub blokuje dostęp.

Najczęściej zadawane pytania

Jaka jest różnica między dostępem do obiektu a dostępem do rekordu?

Dostęp do obiektu (z profili i permission sets) decyduje, czy użytkownik może w ogóle dotknąć obiektu — Read, Create, Edit, Delete — oraz które pola widzi. Dostęp do rekordu (model współdzielenia) decyduje, które konkretne rekordy tego obiektu może zobaczyć. Potrzebujesz obu.

Profile czy permission sets — czego powinienem używać?

Oba istnieją, ale nowoczesne podejście jest oparte na permission sets: utrzymuj profile minimalne jako bazę i przyznawaj dodatkowy dostęp przez permission sets oraz permission set groups. Użytkownik ma jeden profil, ale może mieć wiele permission sets, co ułatwia przypisywanie i audytowanie dostępu.

Czy sharing rules przyznają dostęp do obiektu?

Nie. Sharing rules jedynie rozszerzają dostęp na poziomie rekordu. Jeśli użytkownik nie ma uprawnienia Read do obiektu przez swój profil lub permission set, żadna sharing rule nie pokaże mu ani jednego rekordu. Uprawnienie do obiektu jest bramą; sharing decyduje, które rekordy przez nią przejdą.

Jak profil może nadpisać sharing rule?

Przez View All i Modify All. Te uprawnienia — na poziomie obiektu lub jako „View All Data”/„Modify All Data” w skali całej organizacji — pozwalają użytkownikowi widzieć lub edytować każdy rekord niezależnie od współdzielenia. Stoją ponad modelem sharingu, więc uprawnienie może nadpisać to, co sharing by ograniczył.