Organization-Wide Defaults (OWD) in Salesforce, spiegati

Gli org-wide defaults sono il punto da cui parte ogni decisione di sharing in Salesforce. Impostali correttamente e il resto del modello — gerarchia dei ruoli, sharing rule, condivisioni — avrà fondamenta solide su cui costruire. Sbaglia (di solito impostandoli troppo aperti) e nessuna sharing rule per quanto ingegnosa potrà rimediare. Questa guida spiega cosa sono e come impostarli bene.

Cosa sono gli org-wide defaults

Gli Organization-Wide Defaults (OWD) definiscono il livello di accesso di base che gli utenti hanno ai record che non possiedono, per ogni oggetto. Sono l”impostazione più restrittiva; tutto il resto esiste per ampliare l”accesso al di sopra di questo pavimento.

Gli org-wide defaults sono il pavimento. La gerarchia dei ruoli e le sharing rule sono i modi con cui sollevi specifiche persone al di sopra di esso. Nessuno strumento standard ti permette di scendere al di sotto.

Ecco perché l”OWD è il primo livello del modello di accesso ai record.

I livelli di accesso

L”OWD di ogni oggetto è impostato su uno dei seguenti valori:

Livello	Chi può vedere / fare cosa
Private	Solo il proprietario (e gli utenti che gli stanno sopra nella gerarchia dei ruoli) può visualizzare
Public Read Only	Chiunque abbia accesso all”oggetto può visualizzare; solo il proprietario può modificare
Public Read/Write	Chiunque abbia accesso all”oggetto può visualizzare e modificare
Controlled by Parent	L”accesso segue il record master/parent correlato

Alcuni oggetti offrono varianti aggiuntive (ad esempio Read/Write/Transfer per lead e case).

Default interni ed esterni

Molti oggetti consentono di impostare org-wide defaults interni ed esterni separati. Il default esterno governa gli utenti Experience Cloud (community) e portal e può — e di solito dovrebbe — essere più restrittivo di quello interno, così i pubblici esterni non ereditano l”accesso più ampio di cui dispone il tuo personale.

Best practice: partire restrittivi, aprire in modo deliberato

La regola d”oro:

Imposta l”OWD sul livello più restrittivo che il business può tollerare — di solito Private — poi amplia l”accesso con la gerarchia dei ruoli e le sharing rule.

Il motivo è la direzione del modello di sharing. L”accesso è additivo: puoi sempre aggiungere accesso sopra una baseline Private, ma non puoi usare le sharing rule per sottrarre un accesso che un OWD troppo aperto ha già concesso a tutti. Partire da Private mantiene il modello intenzionale, verificabile e facile da interpretare.

Un metodo rapido per scegliere

Per ogni oggetto, chiediti: un dipendente qualsiasi che non possiede questo record dovrebbe vederlo per impostazione predefinita?

• No, mai → Private.
• Può leggerlo ma non modificarlo → Public Read Only.
• Chiunque può modificarlo liberamente → Public Read/Write (raro per dati sensibili).

Modificare un OWD dopo il go-live

• Ampliare un OWD (ad esempio Private → Public Read Only) è a basso rischio — concede solo più accesso.
• Restringere un OWD (Public → Private) è la modifica da pianificare. Innesca una ricalcolazione dello sharing e può rimuovere accessi su cui gli utenti fanno attualmente affidamento. Testa in una sandbox e comunica prima di rilasciare.

Perché l”OWD è la prima cosa da verificare

Poiché ogni altro meccanismo si costruisce su di esso, un OWD troppo aperto gonfia silenziosamente ciò che tutti possono vedere — e resta invisibile finché qualcuno non chiede “un momento, chi può vedere tutti questi record?”. Quando esamini gli accessi, l”OWD è la baseline che spiega le sorprese più grandi.

AgentForceAccess rende leggibile quella baseline: chiedi perché un utente può vedere un record e ti dice quando la risposta è semplicemente “l”org-wide default è Public” — invece di una regola o condivisione specifica — così correggi la causa al livello giusto.

Domande frequenti

Cosa significa ciascun livello di accesso OWD?

Private — solo il proprietario e gli utenti che gli stanno sopra nella gerarchia dei ruoli possono vedere il record. Public Read Only — chiunque abbia accesso all'oggetto può visualizzare, solo il proprietario può modificare. Public Read/Write — chiunque può visualizzare e modificare. Controlled by Parent — l'accesso segue il record master correlato.

Perché dovrei partire da Private?

Perché lo sharing è additivo: puoi sempre ampliare l'accesso con la gerarchia dei ruoli e le sharing rule, ma non puoi usarle per revocare un accesso che un OWD troppo aperto ha già concesso. Partire da Private e allargare in modo deliberato mantiene il modello intenzionale e verificabile.

Cosa sono gli org-wide defaults interni ed esterni?

Molti oggetti consentono di impostare un default separato per gli utenti esterni — utenti Experience Cloud / community e portal — che può essere più restrittivo del default interno. Questo evita che i pubblici esterni ereditino l'accesso di cui dispongono i tuoi utenti interni.

Posso ridurre l'accesso per un oggetto dopo il go-live?

Sì, ma restringere un OWD innesca una ricalcolazione dello sharing e può rimuovere accessi su cui le persone fanno attualmente affidamento, quindi testa in una sandbox e comunica la modifica. Ampliare un OWD è a basso rischio; restringerlo è la modifica da pianificare con cura.