Een gebruiker ziet een record niet dat hij wel zou moeten zien

Het spiegelbeeld van “waarom kan deze gebruiker dat record zien” komt net zo vaak voor: iemand zou een record moeten kunnen zien en kan dat niet. Het goede nieuws is dat toegang in Salesforce een vaste reeks controles doorloopt, zodat je het probleem methodisch kunt isoleren in plaats van te gokken.

De twee controles die elke recordtoegang moet doorstaan

Salesforce verleent alleen toegang als beide controles slagen:

1. Objectniveau — heeft de gebruiker CRUD op het object, en field-level security op de relevante velden? (Vanuit profielen en permission sets.)
2. Recordniveau — verleent het sharing-model dit specifieke record?

Faalt er één van beide, dan blijft het record verborgen. De eerste taak is dus uitzoeken welke controle faalt — en het symptoom verraadt het.

Lees eerst het symptoom

Symptoom	Falende controle	Ga naar
Kan het object/tabblad helemaal niet vinden	Objectrecht of app-/tabzichtbaarheid	Stap 1
Ziet het object wel, maar één record niet	Sharing op recordniveau (of restriction rule)	Stap 3
Opent het record wel, maar velden zijn leeg	Field-level security	Stap 2
Zag het gisteren wel, vandaag niet	Een recente wijziging / herberekening	Stap 4

Stap 1 — Objectrechten en zichtbaarheid

Als de gebruiker het object of het tabblad niet kan bereiken:

• Controleer het Read-recht op het object in zijn profiel of een permission set.
• Controleer of de app en het tabblad zichtbaar voor hem zijn.

Geen objecttoegang betekent geen records, ongeacht sharing. Los dit eerst op. (Faalt het bij het opslaan van een record in plaats van het bekijken, dan ligt de oorzaak meestal bij een gerelateerd record dat de gebruiker niet kan bereiken — zie insufficient access rights on cross-reference id.)

Stap 2 — Field-level security

Als het record wel opent maar specifieke velden leeg zijn, is de toegang op recordniveau in orde — field-level security verbergt de velden. Verleen FLS voor die velden op het profiel of een permission set van de gebruiker. (Dit is een instelling van profiel/permission set, geen sharing — zie profielen vs permission sets vs sharing.)

Stap 3 — Sharing op recordniveau

Als de gebruiker objecttoegang heeft maar één record niet kan bereiken, doorloop dan het sharing-model:

• Org-wide default — staat die op Private, dan ziet de gebruiker alleen records die hij bezit, records van iemand lager in de rolhiërarchie, of records die via een rule/team/handmatige share zijn verleend. Geldt geen daarvan, dan heb je je antwoord — voeg een sharing rule, teamlidmaatschap of handmatige share toe.
• Rolhiërarchie — staat de gebruiker daadwerkelijk boven de eigenaar? Zo niet, dan is er geen roll-up.
• Een restriction rule filtert hem eruit — restriction rules beperken de toegang bovenop sharing. De gebruiker heeft mogelijk toegang via sharing, maar wordt uitgesloten door de criteria van een restriction rule. Controleer de restriction rules op het object voor de permission set van de gebruiker.

Stap 4 — Recente wijzigingen en herberekening

Als de toegang is verdwenen:

• Zoek naar wijzigingen in eigenaarschap, de rolhiërarchie, sharing rules, een restriction rule of de permission set-toewijzingen van de gebruiker — elk hiervan kan toegang wegnemen.
• Controleer of een sharing-herberekening klaar is. Na wijzigingen in eigenaarschap/rol/regels verwerkt Salesforce shares asynchroon opnieuw, en de toegang kan tijdens dat venster achterlopen.

Een diagnosechecklist

1. Kunnen ze het object/tabblad bereiken? → objectrecht + app-/tabzichtbaarheid.
2. Worden de velden weergegeven? → field-level security.
3. Staat de OWD op Private zonder toepasselijke share? → voeg sharing toe.
4. Staan ze boven de eigenaar in de hiërarchie? → indien nodig.
5. Sluit een restriction rule ze uit? → pas de criteria aan.
6. Een recente wijziging of herberekening in uitvoering? → wachten / terugdraaien.

De eerste falende controle is je oplossing. En let op het omgekeerde probleem — te veel toegang — in een gebruiker ziet een record dat hij niet zou mogen zien.

Spring direct naar de falende laag

Het trage deel is het testen van elke laag op zijn beurt, vaak door in te loggen als de gebruiker. AgentForceAccess maakt dat overbodig: vraag waarom een gebruiker een record niet kan zien en het rapporteert welke controle hem blokkeert — een objectrecht, field-level security, een ontbrekende share of een restriction rule — zodat je meteen de juiste laag herstelt.

Veelgestelde vragen

De gebruiker ziet het object wel, maar één specifiek record niet. Waarom?

Dat is een probleem op recordniveau. Met een Private org-wide default ziet een gebruiker alleen records die hij bezit, records van iemand lager in de rolhiërarchie, of records die via een sharing rule, team of handmatige share worden verleend. Geldt geen daarvan, dan blijft het record verborgen. Ook kan een restriction rule het eruit filteren.

De gebruiker kan het record openen, maar belangrijke velden zijn leeg. Waarom?

Dat is field-level security, geen record sharing. De gebruiker heeft toegang tot het record, maar zijn profiel of permission sets verbergen die velden. Verleen field-level security voor de velden op de relevante permission set.

De gebruiker ziet het object of tabblad helemaal niet. Wat is er mis?

Waarschijnlijk ontbreekt het Read-recht op het object, of de app/het tabblad is verborgen voor zijn profiel. Objectrechten en tab-/appzichtbaarheid komen uit profielen en permission sets; los die eerst op voordat je naar het sharing-model kijkt.

Gisteren werkte de toegang nog en nu niet meer. Wat is er veranderd?

Zoek naar een recente wijziging in eigenaarschap, de rolhiërarchie, sharing rules, een restriction rule of de permission sets van de gebruiker; elk hiervan kan toegang wegnemen. Controleer ook of een sharing-herberekening klaar is, want toegang kan achterlopen tijdens herverwerking.