Wie ziet een record in Salesforce? Hoe toegang echt wordt bepaald

Als je een Salesforce-org lang genoeg beheert, vraagt iemand het je vroeg of laat: “Hoe kan deze persoon dat record zien?” Het eerlijke antwoord is dat Salesforce de zichtbaarheid van een record nooit op één plek beslist. Het stapelt meerdere mechanismen op elkaar en verleent de vereniging ervan.

Deze gids loopt elke laag door in de volgorde waarin Salesforce die evalueert, zodat je elke “wie ziet wat”-vraag vanuit de basisprincipes kunt beredeneren.

De ene regel die alles verklaart

Sharing in Salesforce is additief en het meest ruimhartige recht wint. Je begint bij de basislijn die de org-wide defaults vastleggen, en daarna kan elk ander mechanisme er alleen toegang bovenop leggen. Niets in het standaard sharing-model neemt toegang weg.

Wanneer je nagaat waarom een gebruiker een record kan zien, ben je dus nooit op zoek naar de regel die het toestaat en een regel die het blokkeert. Je zoekt naar één enkel recht — want één is genoeg.

Als zelfs maar één mechanisme toegang verleent, heeft de gebruiker toegang. Punt uit.

Laag 1 — Objectrechten bepalen óf, niet welke

Voordat sharing überhaupt in beeld komt, heeft de gebruiker toegang op objectniveau nodig via zijn profiel of permission sets:

• Read / Create / Edit / Delete op het object.
• View All of Modify All op het object, die sharing voor dat object volledig negeren.

Als een gebruiker geen Read-recht heeft op Opportunities, zal geen enkele sharing rule ter wereld hem een opportunity tonen. Objectrechten vormen de poort; het sharing-model is wat er gebeurt nadat je die bent gepasseerd.

Laag 2 — Org-wide defaults bepalen de ondergrens

Org-wide defaults (OWD) leggen de meest restrictieve basislijn voor elk object vast:

• Private — alleen de eigenaar van het record (en wie boven hem staat in de rollenhiërarchie) kan het zien.
• Public Read Only — iedereen kan het bekijken, alleen de eigenaar kan het bewerken.
• Public Read/Write — iedereen kan het bekijken en bewerken.

Alles wat hierna komt, bestaat om de toegang boven deze ondergrens te verbreden voor specifieke personen.

Laag 3 — De rollenhiërarchie rolt toegang omhoog

Als Grant Access Using Hierarchies voor het object is ingeschakeld, erft iedereen die boven de eigenaar van het record in de rollenhiërarchie staat de toegang van die eigenaar. Daarom ziet een salesmanager de deals van zijn medewerkers zonder enige expliciete regel — en het is veruit de meest voorkomende reden voor onverwachte toegang.

Laag 4 — Sharing rules openen toegang zijwaarts

Sharing rules breiden toegang dwars door de hiërarchie uit, naar collega’s en andere takken:

• Ownership-based — deel records die één groep gebruikers bezit met een andere groep.
• Criteria-based — deel records die overeenkomen met veldwaarden (bijv. Region = EMEA) met een groep, rol of territory.

Beide verlenen in één keer toegang aan een groep gebruikers, waardoor een te brede criteria-based regel vaak de boosdoener is wanneer “te veel” mensen iets kunnen zien.

Laag 5 — Handmatige en impliciete shares

• Manual sharing — de knop Share op een record, die één specifieke gebruiker of groep toegang geeft tot dat ene record.
• Implicit sharing — ingebouwd gedrag, zoals toegang tot een parent account die beperkte toegang tot de bijbehorende child cases en contacts impliceert.
• Apex managed sharing — programmatische shares die door custom code worden aangemaakt en vaak het lastigst te herkennen zijn.

Laag 6 — Teams en territories

• Account-, Opportunity- en Case-teams geven de vermelde teamleden toegang tot dat record.
• Enterprise Territory Management verleent toegang op basis van de territories waartoe een gebruiker en een record behoren.

Alles samengevat: hoe je elke toegang traceert

Om de vraag “waarom kan deze gebruiker dit record zien” te beantwoorden, controleer je elke laag tot je een recht vindt:

1. Heeft de gebruiker object-Read (of View All) via profiel/permission set?
2. Staat de OWD voor dit object al op public?
3. Staat hij boven de eigenaar in de rollenhiërarchie?
4. Omvat een of andere sharing rule hem?
5. Bestaat er een handmatige, impliciete of Apex-share?
6. Zit hij in een team of in een overeenkomende territory?

Het eerste “ja” is je antwoord — en onthoud dat er meer dan één kan zijn. Voor de stap-voor-stap-versie van deze tracering, zie een gebruiker kan een record zien dat hij niet zou mogen zien; hetzelfde model bepaalt wie een bestand kan zien, aangezien bestanden de recordtoegang overerven.

Dit is precies het werk dat AgentForceAccess automatiseert: vraag in gewone taal waarom een gebruiker een record kan zien, en het traceert elke laag hierboven en benoemt het exacte recht dat het toestaat.

Veelgestelde vragen

Omzeilt een System Administrator het sharing-model?

Ja. De rechten "View All Data" en "Modify All Data" — die het System Administrator-profiel standaard heeft — omzeilen org-wide defaults, sharing rules en de rollenhiërarchie volledig. De objectspecifieke rechten "View All" / "Modify All" doen hetzelfde voor één enkel object.

Als er twee sharing rules op hetzelfde record van toepassing zijn, welke wint dan?

De meest ruimhartige. Toegang in Salesforce is additief: er wordt toegang verleend op basis van de vereniging van alle van toepassing zijnde regels. Toegang kan nooit worden verminderd door een extra regel toe te voegen — alleen verbreed.

Waarom kan een manager records zien die hem nooit expliciet zijn toegekend?

De rollenhiërarchie geeft managers toegang tot records die in bezit zijn van (of gedeeld zijn met) gebruikers die lager in de hiërarchie staan, zolang "Grant Access Using Hierarchies" voor dat object is ingeschakeld.

Doen objectrechten en sharing-instellingen hetzelfde?

Nee. Objectrechten (op profielen en permission sets) bepalen of een gebruiker een object überhaupt kan benaderen en wat hij ermee mag doen. Het sharing-model bepaalt welke specifieke records van dat object hij kan zien.