Profiles vs permission sets vs sharing rules in Salesforce

“Profiles vs permission sets vs sharing rules” zorgt voor verwarring omdat de drie geen alternatieven zijn — ze beantwoorden verschillende vragen en werken samen. Profiles en permission sets bepalen wat je met een object mag doen; sharing rules bepalen op welke records je dat mag doen. Zo combineren ze.

Het twee-controlemodel

Elke recordtoegang in Salesforce doorloopt twee onafhankelijke controles:

1. Object- en veldcontrole — vanuit profiles en permission sets: heeft de gebruiker CRUD op het object, en field-level security op de velden?
2. Recordcontrole — vanuit het sharingmodel: verlenen de org-wide defaults, de role hierarchy of een sharing rule dit specifieke record?

De objectpermissie is de poort. Sharing bepaalt welke records erdoorheen mogen. Beide moeten slagen.

Dit is de basis van het hele model voor recordtoegang.

Profiles en permission sets: het “wat mag je doen”

Deze sturen toegang op objectniveau en meer aan:

• CRUD per object (Read / Create / Edit / Delete).
• Field-level security — welke velden zichtbaar/bewerkbaar zijn.
• Systeempermissies, app- en tabzichtbaarheid, en de toegang omzeilende View All / Modify All.

Profile vs permission set

• Een gebruiker heeft precies één profile — van oudsher de basislijn van permissies.
• Een gebruiker kan meerdere permission sets (en permission set groups) daarbovenop hebben.

De moderne, aanbevolen aanpak is permission-set-gestuurd: houd het profile minimaal en verleen toegang via permission sets, omdat die makkelijker zijn toe te wijzen, te hergebruiken en te auditen dan een wildgroei aan profiles. (Roles sturen daarentegen de sharing-hiërarchie aan — een aparte as ten opzichte van profiles.)

Sharing rules: het “welke records”

Sharing rules raken object- of veldtoegang helemaal niet. Ze verbreden alleen de toegang op recordniveau — op basis van ownership of criteria — bovenop de org-wide default. Voor hoe ze zich verhouden tot de hiërarchie, zie sharing rules vs role hierarchy.

Cruciaal: een sharing rule kan een ontbrekende objectpermissie niet redden. Geen Read op Opportunities betekent geen opportunities, hoeveel sharing rules ook op de gebruiker wijzen.

Waar permissies sharing overrulen

Er is één plek waar de lagen elkaar kruisen: View All en Modify All (op objectniveau), en View All Data / Modify All Data (voor de hele org). Deze omzeilen het sharingmodel volledig — een gebruiker met deze permissies ziet elk record, ongeacht OWD, hiërarchie of rules. Omdat ze zo krachtig zijn, zijn ze het eerste wat je controleert als toegang verkeerd lijkt. Zie View All / Modify All — de bypass om in de gaten te houden.

Alles samenbrengen

Vraag	Beantwoord door
Mag de gebruiker dit object überhaupt openen?	Profile / permission set (CRUD)
Mag hij dit veld zien?	Field-level security
Welke records van het object kan hij zien?	Sharingmodel
Mag hij sharing omzeilen?	View All / Modify All

Om te zien waarom een gebruiker een record wel of niet kan bereiken, lees je beide assen samen — object-/veldpermissies én de sharing die op dat record van toepassing is.

Beide assen tegelijk lezen

De frictie zit erin dat deze in verschillende delen van de setup leven — profiles en permission sets op de ene plek, het sharingmodel op de andere — en dat je ze mentaal moet doorsnijden. AgentForceAccess doet die doorsnijding voor je: vraag wat een gebruiker met een record mag doen en het houdt rekening met objectpermissies, field-level security én het sharingmodel samen, met exacte vermelding van wat de toegang verleent of blokkeert.

Veelgestelde vragen

Wat is het verschil tussen objecttoegang en recordtoegang?

Objecttoegang (vanuit profiles en permission sets) bepaalt of een gebruiker een object überhaupt mag aanraken — Read, Create, Edit, Delete — en welke velden hij ziet. Recordtoegang (het sharingmodel) bepaalt welke specifieke records van dat object hij kan zien. Je hebt beide nodig.

Profiles of permission sets — wat moet ik gebruiken?

Beide bestaan, maar de moderne aanpak is permission-set-gestuurd: houd profiles minimaal als basislijn en verleen extra toegang via permission sets en permission set groups. Een gebruiker heeft één profile, maar kan meerdere permission sets hebben, wat toegang makkelijker te toewijzen en te auditen maakt.

Verlenen sharing rules objecttoegang?

Nee. Sharing rules verbreden alleen de toegang op recordniveau. Heeft een gebruiker geen Read-permissie op een object via zijn profile of een permission set, dan toont geen enkele sharing rule hem ook maar één record. De objectpermissie is de poort; sharing bepaalt welke records erdoorheen mogen.

Hoe kan een profile een sharing rule overrulen?

Via View All en Modify All. Deze permissies — op objectniveau, of "View All Data"/"Modify All Data" voor de hele org — laten een gebruiker elk record zien of bewerken, ongeacht sharing. Ze staan boven het sharingmodel, dus een permissie kan overrulen wat sharing zou beperken.