La sicurezza in Salesforce si legge su quattro livelli: org, oggetto, campo, record. I primi tre sono permessi e si concedono con profili e permission set; il quarto è il modello di condivisione e vive in Setup → Sharing Settings. Quasi tutte le domande della sezione Security and Access nascono dove i due mondi si toccano: un permesso non mostra record che la condivisione nega, e la condivisione non mostra record di un oggetto che l’utente non ha il permesso di leggere.

Gli organization-wide default sono il pavimento

L’OWD «specifies the default level of access users have to records they don’t own». È il punto di partenza, deliberatamente chiuso: tutto il resto del modello aggiunge accesso, non lo toglie.

OWD Chi legge Chi modifica
Private solo l’owner (più la gerarchia, se attiva) solo l’owner e chi sta sopra di lui
Public Read Only tutti solo l’owner e chi sta sopra di lui
Public Read/Write tutti tutti
Controlled by Parent dipende interamente dal record padre dipende interamente dal record padre

Su Lead e Case esiste anche Public Read/Write/Transfer, che aggiunge il diritto di cambiare owner. La conseguenza la usa mezzo esame: per togliere accesso l’unica strada è abbassare l’OWD e ricostruire quello dei restanti con le sharing rule. Non esiste una regola che sottrae.

Gerarchia dei ruoli e Grant Access Using Hierarchies

La gerarchia dei ruoli serve a «ensure managers have access to the same records as their subordinates»: chi sta sopra vede, e se l’OWD lo consente modifica, i record di chi sta sotto, per l’intero ramo e senza alcuna regola.

Nella related list Organization-Wide Defaults ogni oggetto custom ha la casella Grant Access Using Hierarchies. Tolta quella, «only the record owner and users granted access through sharing features receive access to the object’s records»: è la leva per i dati che i manager non devono ereditare solo perché manager — provvigioni, valutazioni, pratiche riservate. Si disattiva solo sugli oggetti custom, non è disponibile con Controlled by Parent e non ferma View All, Modify All, View All Data, Modify All Data: quelli sono permessi, e i permessi non passano di qui. Chi deve comunque vedere quei record lo ottiene con una sharing rule verso un ruolo o verso «roles and subordinates», oppure con la condivisione manuale.

Sharing rule e condivisione manuale

Le sharing rule sono «automatic exceptions to organization-wide defaults for particular groups of users» e non possono «be stricter than your org-wide default settings».

Owner-based Criteria-based
Cosa seleziona i record il ruolo o il gruppo dell’owner il valore di un campo del record
Se il record cambia owner l’accesso segue il nuovo owner nulla cambia, finché il campo resta uguale
Scenario tipico «i record del team Nord anche al team Sud» «i record con Type uguale a Partner al gruppo Partner Ops»

Entrambe condividono verso utenti, ruoli, «roles and subordinates», territori, «territories and subordinates» e public group, in Read Only o Read/Write; il public group è la risposta ogni volta che il destinatario è un insieme eterogeneo che non coincide con un ruolo. La condivisione manuale copre l’eccezione imprevedibile: le regole «work best when they’re defined for a particular group of users that you can determine or predict in advance».

Controlled by Parent: l’oggetto senza sicurezza propria

Nel lato detail di una master-detail il record non ha owner, non ha OWD, non accetta sharing rule né Share manuale: l’accesso è quello del padre.

Master-detail Lookup
Sicurezza del figlio ereditata (Controlled by Parent) propria: OWD, sharing rule, Share
Owner del figlio non esiste esiste
Campo padre obbligatorio facoltativo
Roll-up summary sul padre sì no

Quando il figlio deve avere una visibilità diversa dal padre la risposta non è una regola sul figlio — non esiste — ma convertire la relazione in lookup e dargli il proprio OWD. La conversione è praticabile finché sul padre non ci sono roll-up summary che aggregano quel figlio; nel senso inverso serve che ogni figlio abbia il campo padre valorizzato.

Territori: una seconda gerarchia, non un doppione

Enterprise Territory Management apre un canale di accesso basato sulla copertura, non sul riporto. La gerarchia dei ruoli rappresenta «management relationships, reporting rollups, approvals»; quella dei territori estende l’accesso «to accounts, opportunities, contacts, and cases» e «rolls up to the role hierarchy». Sono complementari: «duplicating the territory structure in the sales branch of the role hierarchy is unnecessary and redundant». I territori si assegnano con regole su criteri di campo (CAP, fatturato, settore), propagabili ai figli con Apply to child territories; per il forecast aggregato per territorio serve «assign a forecast manager to every territory for which you want rolled-up forecast amounts».

Sulle org grandi il problema è il ricalcolo degli accessi a ogni modifica della gerarchia: si ristruttura dal livello più basso risalendo, il che «avoids having to recalculate access levels to accounts, opportunities, contacts, and cases for the same territories».

Cartelle di report, dashboard ed email

Le cartelle «can be public, hidden, or shared» e si condividono «with roles, permissions, public groups, territories, and license types». La stessa cartella accetta più destinatari insieme, ognuno con il suo livello: dal menu della cartella si sceglie Share, poi il criterio in Share With — per esempio Role and Internal Subordinates — e l’accesso, che nel percorso guidato resta View. Tre pubblici diversi non si servono con tre cartelle ma con tre righe sulla stessa cartella, e il public group impacchetta le persone sparse fra reparti. Le cartelle dei template email seguono la stessa logica.

Distinzione che l’esame ama: la cartella non è il dato. Un report mostra solo i record che chi lo esegue già vede; una dashboard standard mostra i dati del suo running user a chiunque la apra, mentre in una dynamic dashboard «the running user is always the logged-in user».

Profilo, permission set, gruppo, delegato

Il modello moderno è «assign users the Minimum Access - Salesforce profile, and then use permission sets and permission set groups».

Profilo Permission set Permission set group
Quanti per utente uno solo molti molti
A cosa serve baseline e default aggiunge permessi raggruppa permission set per mansione
Esclusive login hours, login IP ranges, default record type, assegnazione dei page layout, policy di password — muting permission set
Toglie permessi no no solo dentro il gruppo, col muting

Sul profilo restano i default e i confini d’ingresso all’org. Un permission set concede «object, field, and user permissions»: View All e Modify All su un singolo oggetto scavalcano OWD e gerarchia per quell’oggetto soltanto — è la risposta quando un team di audit deve leggere tutti i record di un oggetto senza diventare amministratore. View All Data e Modify All Data invece «override all other sharing settings» su tutta l’org.

I permission set group si assegnano in blocco e falliscono quando «their license does not permit the permissions you want to assign»: ecco perché la stessa assegnazione riesce su alcuni utenti e non su altri di pari ruolo. Il muting agisce solo dentro il gruppo — se il permesso arriva dal profilo, da un permission set diretto o da un altro gruppo «the user still has these permissions» — e mutare Read muta a cascata «Create, Edit, Delete, View All Records, and Modify All Records».

La delegated administration è lo strumento a sé: in Setup si crea un gruppo di amministrazione delegata indicando i delegati, i ruoli (e subordinati) sui cui utenti possono agire, i profili e i permission set che possono assegnare, gli oggetti custom che possono amministrare. Il delegato crea utenti, ne reimposta le password e assegna solo ciò che è in elenco, senza toccare le impostazioni dell’org: è la risposta a «il responsabile di filiale gestisce i suoi utenti senza essere amministratore».

Trappole tipiche d’esame

  • Una sharing rule non toglie niente. Per ridurre la visibilità di un oggetto Public Read Only si abbassa l’OWD a Private e si riconcede con le regole: «restringere con una sharing rule» è sbagliato per costruzione.
  • Sul lato detail di una master-detail non esiste condivisione. Niente OWD, niente regole, niente Share: serve la conversione in lookup, che i roll-up summary sul padre bloccano.
  • Grant Access Using Hierarchies disattivata non spegne i permessi. Ferma l’ereditarietà del ruolo, non View All né View All Data, e si disattiva solo sugli oggetti custom.
  • «Leggere tutti i record di un oggetto» non è View All Data, è View All su quell’oggetto: nessun accesso al resto dell’org, nessun permesso di modifica.
  • La cartella non è il dato. Condividere la cartella di una dashboard non allarga la visibilità dei record: quella la decide il running user.
  • Un permission set group che fallisce su alcuni utenti è un problema di licenza, non di ruolo, di gerarchia o di muting.
  • Territori e ruoli non si copiano a vicenda, e la ristrutturazione si fa dal basso verso l’alto.