"View All / Modify All" in Salesforce — de bypass om op te letten
View All en Modify All omzeilen het Salesforce-sharingmodel. Wat ze doen, waar ze vandaan komen, wie je moet controleren en waarom ze tellen voor AI-agents.
Het Salesforce-sharingmodel draait grotendeels om het zorgvuldig verlenen van recordtoegang. View All en Modify All gooien dat overboord — ze laten een gebruiker alles zien of wijzigen en negeren sharing volledig. Ze zijn onmisbaar voor admins en gevaarlijk zodra ze zich verspreiden. Hier lees je wat ze doen en hoe je ze in toom houdt.
Wat ze daadwerkelijk doen
Deze permissies omzeilen het sharingmodel — org-wide defaults, rolhiërarchie, sharing rules, alles:
- View All — elk record van een object zien.
- Modify All — elk record van een object zien, bewerken, verwijderen én overdragen.
Een gebruiker met View All op Cases ziet elke case in de org, zelfs met een Private org-wide default en zonder enige sharing rule in zicht. Sharing geldt voor dat object simpelweg niet voor hem.
Zijn deze aanwezig, dan is de rest van het sharingmodel irrelevant — ze staan erboven.
Twee niveaus: object versus systeembreed
| Permissie | Niveau | Effect |
|---|---|---|
| View All (object) | Eén object | Alle records van dat object zien |
| Modify All (object) | Eén object | Volledige controle over alle records van dat object |
| View All Data | Hele org | (Vrijwel) alle records, alle objecten zien |
| Modify All Data | Hele org | Volledige controle over (vrijwel) alle records, alle objecten |
De object-niveauversies zijn afgebakend en soms legitiem. De systeembrede View All Data / Modify All Data zijn het zware geschut — krachtig, en degene die je het scherpst moet bewaken.
Waar ze vandaan komen
- System Administrator-profiel — wordt standaard geleverd met View All Data en Modify All Data.
- Custom profielen en permission sets — vaak verleend om iets eenmaligs op te lossen (“laat support gewoon alle cases zien”) en daarna vergeten.
Omdat de permissies van een gebruiker de vereniging zijn van hun profiel en elke toegewezen permission set, kunnen deze zich verschuilen in elk van meerdere permission sets — en juist daardoor raak je het overzicht kwijt. Ze hangen nauw samen met profielen en permission sets.
Waarom ze het eerste zijn dat je controleert bij verkeerde toegang
Wanneer een gebruiker een record kan zien dat hij niet zou mogen zien, toont de Sharing-knop misschien niets — omdat de toegang helemaal niet uit sharing komt. View All / Modify All verlenen toegang zonder als share te verschijnen. Sluit ze dus uit voordat je je door sharing rules gaat graven.
Waarom ze dubbel tellen voor AI-agents
Een AI-agent erft de permissies van zijn running user. Draagt die identiteit View All Data, dan kan de agent op verzoek elk record in de org lezen — en omzeilt zo elke sharing rule die je hebt geconfigureerd. Bevestigen dat de identiteit van de agent vrij is van deze permissies is een kernstap in het auditen van toegang vóór uitrol.
Ze onder controle houden
- Inventariseer elk profiel en elke permission set op object-niveau View All/Modify All en systeembreed View All Data/Modify All Data.
- Lijst de gebruikers op die elk ervan hebben, rechtstreeks of via permission sets.
- Pas least privilege toe — vervang generieke View All door afgebakende sharing rules overal waar de toegang niet echt org-breed hoeft te zijn.
- Controleer opnieuw na wijzigingen — een nieuwe permission set kan stilletjes weer een bypass introduceren.
De bypass automatisch zichtbaar maken
Het lastige is dat deze permissies niet opduiken waar je naar sharing zoekt — het is een aparte schakelaar, in elk van vele permission sets, die stilletjes alles anders overrulet. AgentForceAccess neemt ze automatisch mee: wanneer het uitlegt waarom een gebruiker (of de gebruiker van een agent) een record kan zien, wordt “ze hebben View All Data — sharing geldt niet” net zo helder getoond als elke sharing rule, zodat de bypass niet langer het ding is dat je over het hoofd ziet.
Veelgestelde vragen
Wat doen View All en Modify All precies?
Ze geven toegang tot elk record van een object en negeren daarbij het sharingmodel. View All betekent elk record zien; Modify All betekent elk record zien, bewerken, verwijderen en overdragen. De object-niveauversies gelden voor één object; de systeembrede "View All Data" en "Modify All Data" gelden voor (vrijwel) alle objecten tegelijk.
Wie heeft deze permissies standaard?
Het System Administrator-profiel bevat View All Data en Modify All Data. Daarnaast duiken ze op in custom profielen en permission sets — vaak toegevoegd om een eenmalige toegangsbehoefte op te lossen en daarna nooit verwijderd. Audit elk profiel en elke permission set, niet alleen admins.
Waarom zijn deze gevaarlijk voor AI-agents?
Een agent erft de permissies van zijn running user. Heeft die gebruiker View All Data, dan kan de agent op verzoek elk record in de org lezen en omzeilt zo alle sharing die je zorgvuldig hebt geconfigureerd. Bevestig vóór het uitrollen van een agent dat zijn identiteit deze permissies niet draagt.
Hoe vind ik wie View All / Modify All heeft?
Controleer elk profiel en elke permission set op object-niveau View All/Modify All en op systeembreed View All Data/Modify All Data, en lijst vervolgens de toegewezen gebruikers op. Handmatig is dit moeizaam, omdat de permissie uit elke van meerdere permission sets kan komen die een gebruiker heeft.
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