La sicurezza in Business Central online non si gestisce con account locali: l’identità vive in Microsoft Entra ID e l’accesso all’applicazione dipende dalle licenze assegnate in Microsoft 365. Come functional consultant devi saper collegare questi tre livelli — identità, licenza, permessi — e capire quale meccanismo usare in ogni scenario.

Creazione e provisioning degli utenti

In un ambiente online non crei l’utente manualmente dentro Business Central. Il flusso corretto è: assegni la licenza (Essential, Premium, Team Member o Device) nel Microsoft 365 admin center, poi apri la pagina Users e lanci l’azione Update Users from Microsoft 365, che importa gli account e sincronizza il License Type. Il tipo di licenza definisce già un livello di accesso di base (un Team Member ha permessi di lettura ampi ma scrittura molto limitata). Gli utenti non si eliminano: si portano in stato Disabled.

I permission set

Il permesso effettivo si costruisce assegnando permission set all’utente. Ne esistono tre famiglie:

  • Predefiniti: forniti dal sistema o dalle app installate (SUPER, D365 BASIC, D365 BUS FULL ACCESS, ecc.). Sono di tipo System o Extension, in sola lettura: non li modifichi, ma puoi copiarli per partire da una base.
  • Personalizzati (User-Defined / Tenant): li crei da zero o per copia, elencando gli oggetti e i livelli Read / Insert / Modify / Delete / Execute.
  • Generati da recording: dalla pagina del permission set avvii una registrazione, esegui in BC le azioni che l’utente dovrà compiere, la fermi e il sistema deduce automaticamente i permessi sugli oggetti toccati. È il metodo ideale per profilare un ruolo reale senza conoscere a memoria i table/page ID.

Assegnazione in blocco: security group

Per non assegnare i permessi utente per utente si usano le security group (dalla v22 hanno sostituito i vecchi user group). Crei una security group in BC mappata a un gruppo di sicurezza di Microsoft Entra ID, le associ i permission set desiderati e tutti i membri del gruppo Entra ereditano quei permessi. Aggiungere o togliere una persona dal gruppo in Entra ne aggiorna l’accesso senza toccare BC: è la risposta corretta ogni volta che lo scenario parla di “onboarding di molti utenti con lo stesso ruolo”.

Personalizzazione per-utente vs configurazione per-tutti

Attenzione a non confondere due concetti diversi:

  • Personalization (per-utente): il singolo utente entra in modalità di personalizzazione e sposta, nasconde o aggiunge campi. La modifica riguarda solo lui.
  • Configurazione per tutti / profilo (Role Center): ogni utente ha un Profile (Role) che determina il suo Role Center. Un amministratore che entra in Customize su un profilo cambia le pagine per tutti gli utenti assegnati a quel profilo. Se lo scenario chiede “modificare il layout per l’intero reparto vendite”, la risposta è personalizzare il profilo, non i singoli utenti.

User Setup e limiti sui periodi di registrazione

La tabella User Setup serve a vincoli operativi non coperti dai permission set. I campi Allow Posting From / Allow Posting To limitano l’intervallo di date in cui quel utente può registrare. Esiste anche un limite globale in General Ledger Setup: quello vale per tutti, mentre il valore in User Setup è specifico dell’utente e serve a differenziare (es. chiudere il periodo a tutti ma lasciare aperto il contabile). User Setup gestisce anche responsibility center predefiniti e altre restrizioni operative.

Trappole tipiche d’esame

  • Più permission set → somma additiva. I permessi si cumulano: se un set concede Modify e un altro solo Read, l’utente ottiene Modify. Non esiste un “deny” che sovrascrive un allow (a parte i permessi Indirect). Nello scenario “l’utente ha due set, quale accesso ha?”, scegli sempre il livello più permissivo.
  • Effective Permissions. Per capire cosa può davvero fare un utente usa la pagina Effective Permissions, che mostra il permesso risultante e la sorgente (quale set/licenza lo concede). È lo strumento da citare per il troubleshooting, non l’ispezione dei singoli set.
  • License prima dei permission set. Se un utente riceve “insufficient permissions” nonostante il set corretto, spesso il limite è la licenza (es. un Team Member che tenta operazioni Premium). Il permission set non aggira mai il License Type.
  • Nuovi utenti online. Non si “creano” in BC: si assegna licenza in Microsoft 365 e si esegue Update Users from Microsoft 365. Diffida delle risposte che parlano di creazione manuale dell’account.
  • Periodi di registrazione per singolo utente → User Setup, non General Ledger Setup (che è globale).