Restriction rules vs scoping rules vs sharing rules
Sharing rules verruimen toegang, restriction rules beperken die en scoping rules bepalen enkel de standaardweergave. Hoe ze verschillen en wanneer je welke inzet.
Het grootste deel van het Salesforce sharing-model kan toegang alleen maar openen. Restriction rules en scoping rules zijn de nieuwere instrumenten die daar verandering in brengen — maar ze doen heel verschillende dingen, en ze worden makkelijk door elkaar gehaald. Zo hangen alle drie samen.
De kaart in één zin
- Sharing rules — openen toegang. Geven records aan gebruikers die ze anders niet zouden zien.
- Restriction rules — beperken toegang. Filteren records eruit die een gebruiker anders zou mogen zien.
- Scoping rules — richten de weergave. Veranderen welke records standaard verschijnen, zonder de toegang te wijzigen.
Twee hiervan raken de beveiliging; één niet. Dat is het onderscheid dat je scherp moet houden.
Sharing rules: toegang openen
Sharing rules werken bovenop de org-wide default en verlenen extra toegang op basis van eigendom of criteria. Ze kunnen toegang alleen verruimen — nooit versmallen. Wil je opfrissen hoe ze zich verhouden tot de hiërarchie, lees dan sharing rules vs role hierarchy.
Dit is het additieve, meest-permissieve-wint-gedrag dat de kern vormt van het record-toegangsmodel.
Restriction rules: toegang beperken
Restriction rules zijn de uitzondering op “Salesforce sharing opent alleen toegang.” Een restriction rule definieert welke records een gebruiker mag zien en wordt bovenop alles toegepast wat het sharing-model verleende — waarmee het resultaat in feite wordt gefilterd.
Als de org-wide default, de role hierarchy en sharing rules samen een gebruiker 10.000 records zouden tonen, kan een restriction rule dat versmallen tot de subset die aan haar criteria voldoet.
Voorbeeld. Support agents hebben via een sharing rule brede toegang tot Cases, maar de contractors onder hen mogen alleen niet-vertrouwelijke cases zien. Een restriction rule op Case — Confidential = false voor de contractor-permission set — verwijdert de vertrouwelijke records uit wat zij kunnen zien, ook al heeft sharing die technisch gezien aan hen verleend.
Dit is het instrument waar je naar grijpt wanneer het antwoord moet zijn op de vraag “hoe neem ik toegang weg”.
Scoping rules: focus, geen beveiliging
Scoping rules bepalen welke records standaard verschijnen in list views, zoekopdrachten en rapporten — op basis van voorwaarden zoals eigenaar, role of regio. Belangrijk hierbij:
Scoping rules beperken de toegang niet. Een gebruiker kan de scope omschakelen naar “alle records waartoe ik toegang heb” en alles zien wat sharing hem verleent.
Het is een productiviteitsfunctie: laat een drukke rep eerst zijn eigen regio zien, zonder die op te dringen. Als een gebruiker belet moet worden records te zien, zijn scoping rules het verkeerde instrument — gebruik dan restriction rules.
Naast elkaar
| Sharing rules | Restriction rules | Scoping rules | |
|---|---|---|---|
| Effect op toegang | Verruimt | Beperkt | Geen |
| Beveiligingscontrole? | Ja | Ja | Nee (alleen focus) |
| Kan gebruiker omzeilen? | Nee | Nee | Ja (scope omschakelen) |
| Richting | Toegang toevoegen | Toegang wegnemen | Standaardweergave filteren |
| Typische limiet | Veel | ~2 actief/object | ~2 actief/object |
Ze samenbrengen
Een realistisch object zou alle drie kunnen gebruiken: een Private OWD, sharing rules om teams de toegang te geven die ze nodig hebben, een restriction rule om een gevoelige subset weg te snijden voor contractors, en een scoping rule zodat elke gebruiker standaard op zijn eigen regio uitkomt. Elk doet één taak; samen bepalen ze zowel wat gebruikers kunnen zien als wat ze het eerst zien.
De valkuil: effectieve toegang is de som
Door instrumenten die openen, beperken en focussen op elkaar te stapelen, wordt “wat kan deze gebruiker eigenlijk zien?” oprecht moeilijk te beantwoorden door inspectie — sharing-verleningen minus restriction-filters, scoping buiten beschouwing gelaten. Dat is precies de berekening die AgentForceAccess voor je uitvoert: vraag wat een gebruiker echt kan benaderen, en het houdt rekening met de sharing die het verleent én de restriction rules die het terugschalen, in gewone taal.
Veelgestelde vragen
Wat is het verschil in één zin?
Sharing rules verlenen toegang die een gebruiker niet had, restriction rules nemen toegang weg die een gebruiker wel had, en scoping rules filteren alleen de list views en zoekopdrachten vooraf, zonder de toegang aan te tasten.
Kan een restriction rule een sharing rule of de role hierarchy overschrijven?
Ja. Restriction rules werken bovenop het sharing-model en filteren de records die een gebruiker kan zien, zelfs records die de org-wide default, de role hierarchy of sharing rules anders zouden tonen. Zo beperk je toegang in Salesforce echt.
Verbergen scoping rules records voor de beveiliging?
Nee. Scoping rules veranderen alleen de standaardset records die in list views, zoekopdrachten en rapporten verschijnt. Een gebruiker kan de scope omschakelen naar "alle records waartoe ik toegang heb", dus het gaat om focus en productiviteit, niet om beveiliging. Gebruik restriction rules wanneer toegang daadwerkelijk beperkt moet worden.
Gelden er limieten voor deze regels?
Ja. Restriction rules en scoping rules zijn elk doorgaans gemaximeerd op 2 actieve regels per object en beschikbaar voor custom objects plus een selectie standaardobjecten zoals Account, Case, Contact, Event, Lead, Opportunity en Task. Controleer de actuele limieten voor jouw editie.
Bekijk het op je eigen org
AgentForceAccess legt in normale taal uit waarom een gebruiker een record of bestand kan zien — over elk Salesforce share-mechanisme heen.
Vraag vroege toegang aan