Il form: security role, fallback e ordine
Il primo punto in cui si decide chi vede cosa è il form. Da Form settings — raggiungibile dall’area Forms oppure dalla command bar del form designer — il maker trova quattro aree distinte: assegnare i security role a un form, impostare il Form order, impostare il fallback form per una tabella e il Form access checker.
L’assegnazione vera sta sotto Security role, dove si sceglie fra Everyone e Specific security roles; con la seconda si selezionano i ruoli che devono poter aprire quel form, poi si fa Save and Publish. La logica dichiarata è che persone diverse trattano lo stesso dato in modo diverso: un manager vuole scorrere le informazioni, chi lavora sul servizio vuole un form che snellisca l’inserimento.
Qui entra il concetto che l’esame ama. Poiché ogni tabella deve comunque riuscire a mostrare un form a qualunque utente, almeno un form va designato come fallback: quello visibile agli utenti i cui security role non hanno nessun form esplicitamente assegnato. Il fallback riguarda solo i main form. Quick Create, Quick View e Card non possono essere assegnati a security role, e il fallback non si applica a loro. La documentazione suggerisce due strategie: una contingency form con pochissime informazioni, associata a nessun ruolo tranne system administrator, oppure una generic form impostata come fallback per tutti, con i form specializzati posizionati sopra di essa nel Form order.
Non confondere le due leve, ed è una domanda d’esame classica: il Form order decide quale form appare per default fra quelli disponibili, non chi può vederli. Una terza via, citata come opzione ulteriore, è rendere inactive un main form.
Le public view: si filtra il view selector, non i dati
L’accesso alle view si governa altrove e con una logica diversa. Le view sono di tre tipi: personal (di proprietà del singolo, visibili solo a lui se non le condivide), system (quelle da cui l’applicazione dipende: Quick Find, Advanced Find, Associated, Lookup) e public (generiche, accessibili a tutti gli utenti dell’app tramite il view selector).
Le public view si gestiscono con i security role selezionando la view non predefinita e usando View settings sulla command bar, poi Specific security roles. Due vincoli da ricordare: solo le public view possono essere gestite così, e le public view default non possono ricevere security role. Il comportamento richiede inoltre che la proprietà EnableRoleBasedSystemViews degli orgdbsettings sia impostata a true tramite l’OrganizationSettingsEditor tool.
Il punto che genera più confusione è la portata dell’effetto. Questa configurazione filtra le view che compaiono nel view selector della table list: le altre restano raggiungibili dall’opzione Manage and share views, e subgrid e associated grid continuano a mostrare tutte le view. Soprattutto, l’accesso ai dati resta governato dai privilegi del security role: avere accesso a una view non significa avere accesso ai dati che quella view mostra. Due dettagli operativi: passare da Specific security roles a Everyone può richiedere fino a 24 ore o il logout dell’utente, e i ruoli elencati in View settings provengono dalla root business unit.
Nota sullo stato: l’articolo dedicato non porta banner di preview, mentre la pagina sulle view lo linka come funzionalità “(preview)”. Se in esame compare una domanda sullo stato di questa feature, ragiona sul comportamento descritto invece che sull’etichetta.
Condivisione dell’app e privilegi che la rendono visibile
Il terzo punto è l’app stessa. Da Apps, con … e poi Share, si condivide con tutti i membri di uno o più security role oppure con un singolo utente o team dalla lista People. Chi condivide deve avere un security role con privilegi pari o superiori a quello che sta assegnando, tipicamente System Administrator o System Customizer, e l’utente deve già esistere nell’environment: non basta essere utente Microsoft 365. A differenza delle canvas app, la condivisione non invia una mail: il link si recupera da Details, campo Web link.
Separato dalla condivisione c’è il privilegio che rende l’app visibile, e questa distinzione è terreno d’esame. Chi ha privilegi di write e create sulla tabella Model-driven App diventa di fatto una persona maker e vede tutte le app dell’environment; chi ha solo read deve anche avere i security role associati all’app. È per questo che un utente con il solo ruolo Basic User vede unicamente le app a cui quel ruolo è stato assegnato. System Administrator, System Customizer ed Environment Maker hanno create, read e write su quella tabella — ma Environment Maker da solo non dà accesso alle tabelle core e custom necessarie per lavorare sui dati.
Chart e dashboard
I system chart sono di proprietà dell’organizzazione: la documentazione dice esplicitamente che “System charts can’t be assigned or shared with specific app users”, quindi sono disponibili a chiunque possa leggere i dati. Si creano da Solutions, aprendo la tabella e scegliendo Charts sotto Data experiences, poi New chart. Nel chart designer si sceglie la Column (asse verticale), l’Aggregate e il Chart type fra Column, Bar, Pie o Doughnut; il passo successivo definisce la categoria, cioè l’asse orizzontale. Per le colonne non numeriche gli unici aggregati sono Count: All e Count: Non-empty; per le numeriche ci sono anche Average, Max, Min e Sum, e i valori NULL non entrano nel calcolo di minimo, massimo e media mentre gli zeri sì. Si possono aggiungere serie con Add a series e categorie con Add a category, fino a due categorie e una serie in un comparison chart; Stacked e 100% Stacked valgono solo per bar, column e area. Limite da ricordare: i chart mostrano view che restituiscono fino a 50.000 record. La pagina del chart designer porta un banner di prerelease, quindi non presentare quella specifica esperienza come definitiva.
Le dashboard sono raccolte di chart e si dividono in user dashboard, che un utente crea e vede solo lui, e system dashboard, create da admin o customizer e visibili a tutti gli utenti dell’app dopo la pubblicazione; un utente può impostare la propria come default sovrascrivendo quella di sistema. I layout offerti alla creazione sono 2-column overview, 3-column overview, 3-column overview (varied width), 4-column overview e Power BI embedded, con un massimo di sei componenti; ogni componente si configura scegliendo Record Type, View e Chart. Accanto alle dashboard standard esistono le interactive experience dashboard, che sono esplicitamente basate sui security role e si presentano come multi-stream o single-stream: lì l’abilitazione avviene con il comando Enable security roles e l’opzione Display only to these selected security roles. Ultimo tassello di visibilità: nell’app designer, per impostazione predefinita tutti i form, le view e i chart sono selezionati e disponibili nell’app; per restringere il set bisogna selezionare esplicitamente quelli voluti fra In this app e Not in this app.