Organization-Wide Defaults (OWD) in Salesforce uitgelegd

Org-wide defaults zijn waar elke beslissing over delen in Salesforce begint. Krijg je ze goed, dan heeft de rest van het model — rolhiërarchie, sharing rules, shares — een schone basis om op voort te bouwen. Krijg je ze fout (meestal te open), dan zal geen enkele slimme sharing rule dat nog repareren. Deze gids legt uit wat ze zijn en hoe je ze goed instelt.

Wat org-wide defaults zijn

Organization-Wide Defaults (OWD) definiëren het basisniveau van toegang dat gebruikers hebben tot records waarvan zij geen eigenaar zijn, per object. Het is de meest beperkende instelling; al het andere bestaat om toegang boven deze vloer te openen.

Org-wide defaults zijn de vloer. Rolhiërarchie en sharing rules zijn de manieren waarop je specifieke mensen erboven tilt. Niets standaards laat je eronder gaan.

Daarom is OWD de eerste laag in het recordtoegangsmodel.

De toegangsniveaus

De OWD van elk object wordt ingesteld op een van de volgende:

Niveau	Wie kan wat zien / doen
Private	Alleen de eigenaar (en gebruikers boven hem in de rolhiërarchie) kan het bekijken
Public Read Only	Iedereen met objecttoegang kan het bekijken; alleen de eigenaar kan het bewerken
Public Read/Write	Iedereen met objecttoegang kan het bekijken en bewerken
Controlled by Parent	De toegang volgt het gerelateerde master-/parentrecord

Sommige objecten bieden extra varianten (bijv. Read/Write/Transfer voor leads en cases).

Interne versus externe defaults

Veel objecten laten je aparte interne en externe org-wide defaults instellen. De externe default regelt Experience Cloud (community)- en portalgebruikers en kan — en zou meestal moeten — beperkender zijn dan de interne, zodat externe doelgroepen niet de bredere toegang erven die je medewerkers hebben.

Best practice: begin beperkend, open bewust

De gouden regel:

Stel de OWD in op het meest beperkende niveau dat het bedrijf kan verdragen — meestal Private — en open vervolgens toegang met de rolhiërarchie en sharing rules.

De reden is de richting van het deelmodel. Toegang is additief: je kunt altijd toegang toevoegen bovenop een Private-basislijn, maar je kunt geen sharing rules gebruiken om toegang af te trekken die een te open OWD al aan iedereen heeft uitgedeeld. Beginnen met Private houdt het model doelbewust, controleerbaar en gemakkelijk te doorgronden.

Een snelle manier om te kiezen

Vraag je voor elk object af: zou een willekeurige medewerker die geen eigenaar van dit record is het standaard moeten zien?

• Nee, nooit → Private.
• Ze mogen het lezen maar niet wijzigen → Public Read Only.
• Iedereen mag het vrij bewerken → Public Read/Write (zelden voor gevoelige data).

Een OWD wijzigen nadat je live bent gegaan

• Het openen van een OWD (bijv. Private → Public Read Only) is laag risico — het verleent alleen meer toegang.
• Het aanscherpen van een OWD (Public → Private) is de wijziging die je moet plannen. Het activeert een sharing-herberekening en kan toegang wegnemen waarop gebruikers op dit moment vertrouwen. Test in een sandbox en communiceer voordat je het doorvoert.

Waarom OWD het eerste is om te auditen

Omdat elk ander mechanisme erop voortbouwt, blaast een te open OWD stilletjes op wat iedereen kan zien — en het blijft onzichtbaar totdat iemand vraagt: “wacht eens, wie kan deze allemaal zien?” Wanneer je toegang beoordeelt, is OWD de basislijn die de grootste verrassingen verklaart.

AgentForceAccess maakt die basislijn leesbaar: vraag waarom een gebruiker een record kan zien en het vertelt je wanneer het antwoord simpelweg “de org-wide default is Public” is — versus een specifieke rule of share — zodat je de oorzaak op de juiste laag aanpakt.

Veelgestelde vragen

Wat betekent elk OWD-toegangsniveau?

Private — alleen de eigenaar en gebruikers boven hem in de rolhiërarchie kunnen het record zien. Public Read Only — iedereen met objecttoegang kan het bekijken, alleen de eigenaar kan het bewerken. Public Read/Write — iedereen kan het bekijken en bewerken. Controlled by Parent — de toegang volgt het gerelateerde masterrecord.

Waarom zou ik met Private moeten beginnen?

Omdat delen additief is: je kunt toegang altijd verruimen met de rolhiërarchie en sharing rules, maar je kunt ze niet gebruiken om toegang terug te halen die een te open OWD al heeft verleend. Beginnen met Private en bewust verruimen houdt het model doelbewust en controleerbaar.

Wat zijn interne versus externe org-wide defaults?

Veel objecten laten je een aparte default instellen voor externe gebruikers — Experience Cloud / community- en portalgebruikers — die beperkender kan zijn dan de interne default. Dit voorkomt dat externe doelgroepen de toegang erven die je interne gebruikers hebben.

Kan ik de toegang voor één object verlagen nadat we live zijn gegaan?

Ja, maar het aanscherpen van een OWD activeert een sharing-herberekening en kan toegang wegnemen waarop mensen op dit moment vertrouwen, dus test in een sandbox en communiceer de wijziging. Een OWD openen is laag risico; er een beperken is de wijziging die je zorgvuldig moet plannen.