Een gebruiker ziet een record dat niet zou mogen — zo vind je waarom

Waarom kan deze persoon dat record zien? is de meest gestelde toegangsvraag in Salesforce — en de moeilijkste om met het blote oog te beantwoorden, want het platform bepaalt zichtbaarheid nooit op één plek. Het verleent de vereniging van meerdere mechanismen. Deze gids geeft je een herhaalbare volgorde om degene te vinden die de toegang heeft geopend.

Eerst het mentale model

Sharing in Salesforce is additief en de meest permissieve wint. Je zoekt niet naar een regel die toegang toestaat én een regel die hem blokkeert. Je zoekt naar welke enkele grant dan ook, want één is genoeg. (Voor de volledige gelaagdheid, zie wie kan een record in Salesforce zien.)

Als ook maar één mechanisme toegang verleent, heeft de gebruiker die. Jouw taak is uitzoeken welke.

Stap 1 — Lees de Sharing-knop

Klik op het record op Sharing (beschikbaar voor objecten waarvan de org-wide default niet volledig openbaar is). De lijst toont gebruikers met toegang en een kolom Reason — Owner, Role Hierarchy, Sharing Rule, Manual Share, Team, enzovoort. In de meeste gevallen benoemt dit direct je boosdoener.

Staat de gebruiker daar helemaal niet in maar ziet hij het record toch, vermoed dan een bypass op profielniveau — ga naar Stap 2.

Stap 2 — Sluit bypasses op permissieniveau uit

Deze negeren het sharingmodel volledig:

• View All Data / Modify All Data (systeempermissies, bijvoorbeeld op het System Administrator-profiel).
• View All / Modify All op objectniveau voor dat specifieke object.

Heeft de gebruiker een van deze via een profiel of een permission set, dan verbergen sharingwijzigingen het record niet. Je moet de permissie verwijderen. Controleer hun profiel én elke toegewezen permission set.

Stap 3 — Loop de sharinglagen van boven naar beneden door

Als het werkelijk om een sharing-grant gaat, bepaal dan welke laag:

Org-wide default staat te open

Als de OWD van het object Public Read Only of Public Read/Write is, ziet iedereen met objecttoegang elk record. De oplossing is structureel — verscherp de org-wide default en verleen toegang bewust opnieuw.

Rolhiërarchie rolt toegang naar boven door

Als de gebruiker boven de recordeigenaar in de rolhiërarchie staat en “Grant Access Using Hierarchies” aan staat, erft hij automatisch de toegang van de eigenaar. Dit is de meest voorkomende verrassing.

Een te brede sharing rule

Een criteria-based regel zoals Region = EMEA → delen met role X kan veel meer mensen omvatten dan bedoeld, vooral na data- of rolwijzigingen. Beoordeel de regels die de rol, public groups of territory van de gebruiker als doel hebben.

Een handmatige of impliciete share

• Handmatige share: iemand heeft de Share-knop van het record gebruikt.
• Impliciete share: toegang tot een bovenliggend Account geeft beperkte leestoegang tot de onderliggende Cases en Contacts. Deze vergeet men voortdurend — en hij is altijd alleen-lezen.
• Apex managed sharing: custom code heeft de share aangemaakt; de Sharing-knop toont hem, maar de oorsprong zit in code.

Teams en territories

Lidmaatschap van een Account-/Opportunity-/Case-team, of een matchende territory onder Enterprise Territory Management, verleent elk onafhankelijk toegang.

Stap 4 — Bevestig dat het geen herberekeningsvertraging is

Als de toegang inconsistent oogt, kijk je mogelijk naar sharing-herberekening die afrondt na een recente wijziging in eigenaarschap, rol of regel. Laat die voltooien voordat je een bug verklaart.

Een diagnose-checklist

1. Sharing-knop → lees de Reason voor die gebruiker.
2. Profiel + permission sets → enige View All / Modify All?
3. OWD te open voor dit object?
4. Gebruiker boven de eigenaar in de rolhiërarchie?
5. Een sharing rule (vooral criteria-based) die hem omvat?
6. Handmatige, impliciete of Apex share?
7. Teamlid of matchende territory?
8. Recente wijziging → wacht op herberekening.

De eerste “ja” is je antwoord — en er kan meer dan één pad zijn dat dezelfde toegang verleent. Voor het tegenovergestelde probleem — een gebruiker die een record niet kan zien dat hij wel zou moeten zien — zie de diagnose-checklist voor ontbrekende toegang.

Dit in seconden in plaats van een hele middag doen

Acht lagen aflopen per gebruiker-recordpaar, over profielen, permission sets en zes sharingmechanismen, is precies het handwerk dat echte blootstelling verbergt. AgentForceAccess doet het voor je: vraag in gewone taal waarom een gebruiker een record kan zien, en het traceert elke laag en benoemt de exacte grant — zodat je rechtstreeks naar de oplossing gaat.

Veelgestelde vragen

Wat is de snelste eerste controle?

Open het record, klik op de Sharing-knop en lees de kolom "Reason" voor die gebruiker. Die benoemt het mechanisme dat toegang verleent — Owner, Role Hierarchy, Sharing Rule, Manual, enzovoort — voor de meeste standaardobjecten. Controleer ook of de gebruiker niet simpelweg "View All Data" of "View All" op objectniveau heeft.

De Sharing-knop zegt "Role Hierarchy" — wat nu?

Iemand boven wie de gebruiker in de rolhiërarchie staat, is eigenaar van het record (of heeft het gedeeld gekregen), en "Grant Access Using Hierarchies" staat aan voor het object. Om die toegang weg te nemen zou je de hiërarchie, het eigenaarschap of de hiërarchietoegang voor custom objects moeten wijzigen — geen van alle lichtvaardig.

Kan een profielpermissie, en niet sharing, de oorzaak zijn?

Ja. "View All Data"/"Modify All Data" en "View All"/"Modify All" op objectniveau omzeilen het sharingmodel volledig. Heeft de gebruiker een van deze, dan verbergt geen enkele sharingwijziging het record — je moet dan de permissie zelf verwijderen.

Waarom verschijnt en verdwijnt de toegang met tussenpozen?

Sharing-herberekening. Na wijzigingen in eigenaarschap, rolverplaatsingen of regelaanpassingen verwerkt Salesforce de shares asynchroon opnieuw. In dat tijdvenster kan de toegang inconsistent lijken. Laat de herberekening afronden voordat je concludeert dat er een configuratiefout is.