Il modello di sicurezza di Dataverse è a più livelli: combina l’appartenenza organizzativa (business unit), l’aggregazione degli utenti (team), l’insieme di permessi assegnati (security role) e la protezione delle singole colonne (field security profile). Come Customer Experience Analyst su Dynamics 365 Sales devi saper scegliere quale leva usare per ogni requisito: “chi vede quali record” e “chi vede quali colonne dentro quei record”.

Business unit: la gerarchia organizzativa

Ogni environment ha una root business unit creata automaticamente; da essa deriva un albero gerarchico. Ogni utente e ogni team appartiene a una sola business unit. La BU non è solo organizzativa: è l’unità di scoping su cui si valutano gli access level dei privilegi. Modellare le BU rispecchiando l’organizzazione reale (es. filiali, regioni) permette di isolare i dati per reparto senza scrivere logica custom.

Team: owner team vs access team

I team aggregano utenti che devono condividere accesso.

  • Owner team: può possedere record (è il valore del campo Owner) ed è associato a una BU. I membri ereditano i security role assegnati al team. Utile quando un gruppo stabile deve avere gli stessi permessi.
  • Access team: non possiede record e non ha security role. Concede accesso a livello di singolo record tramite sharing, tipicamente via access team template che definisce i diritti (Read/Write/Share…). Ideale per collaborazione dinamica su una opportunity specifica, senza creare team statici.

Security role: privilegi e access level

Un security role è un insieme di privilegi per tabella: Create, Read, Write, Delete, Append, Append To, Assign, Share. Ogni privilegio ha un access level che ne definisce la profondità:

  • User (Basic): solo i record di cui l’utente è owner o che gli sono stati condivisi.
  • Business Unit (Local): tutti i record della propria BU.
  • Parent: Child Business Units (Deep): la propria BU più le BU figlie.
  • Organization (Global): tutti i record dell’environment.

I ruoli sono cumulativi: quando un utente ha più ruoli (diretti o ereditati da owner team) vince il permesso meno restrittivo. Non esiste un “deny” esplicito: si costruisce concedendo solo il minimo necessario.

Field security profile: colonne riservate

Quando una colonna contiene dati sensibili (es. margini, dati finanziari, sconti negoziati) la si marca come secured abilitando la column security sulla colonna. Da quel momento la colonna è nascosta a tutti per default, indipendentemente dai security role. L’accesso si concede tramite un field security profile, che assegna a utenti/team i permessi Read, Update, Create sulla colonna. Il System Administrator vede le colonne secured senza profilo.

Confronti chiave

  • Field-level security vs privilegio del security role: il security role governa l’accesso al record/tabella; il field security profile governa l’accesso alla singola colonna. Sono due gate distinti e indipendenti: servono entrambi.
  • Team (owner) vs record sharing: l’owner team dà accesso strutturale e stabile tramite ruoli ereditati; lo sharing (anche via access team) dà accesso puntuale a un singolo record. Preferisci lo sharing per eccezioni, i ruoli/team per regole permanenti.

Trappole tipiche d’esame

  • Scenario: un utente ha un security role con Read a livello Organization su Opportunity ma non vede la colonna “Profit Margin” marcata come secured → Risposta giusta: aggiungerlo a un field security profile che concede Read su quella colonna; il ruolo permissivo non espone da solo una colonna secured.
  • Scenario: serve dare accesso temporaneo a una singola opportunity a colleghi di un altro reparto → Risposta giusta: usare un access team (o sharing sul record), non creare una nuova business unit o allargare il security role.
  • Scenario: un utente deve vedere i record della propria filiale e di quelle subordinate → Risposta giusta: access level Parent: Child Business Units, non Organization.
  • Scenario: i membri di un gruppo devono possedere i record e avere gli stessi permessi → Risposta giusta: owner team con security role assegnato, non un access team (che non possiede record né ha ruoli).
  • Scenario: due ruoli assegnati danno Write rispettivamente a livello User e Business Unit → Risposta giusta: prevale il meno restrittivo (Business Unit); i privilegi sono cumulativi.