Public view: che cosa definisce una vista e dove si configura
La documentazione di Power Apps distingue tre tipi di vista: personal view, system view e public view. Le personal view appartengono al singolo utente e restano invisibili agli altri finché non le condivide. Le system view sono viste speciali da cui l’applicazione dipende — Quick Find, Advanced Find, Associated, Lookup — non compaiono nel view selector e non si possono eliminare né disattivare. Le public view sono invece quelle di uso generale: sono importanti perché tutti gli utenti dell’app vi accedono dal view selector quando vengono rese disponibili, e possono essere riusate in un subgrid su un form o come lista in una dashboard.
Una vista definisce cinque cose: le colonne da mostrare, il loro ordine, la larghezza di ciascuna, l’ordinamento predefinito e i filtri predefiniti che restringono i record visualizzati. Quando crei una tabella custom ottieni già una combinazione di viste: due public (Active e Inactive, con il nome plurale della tabella), più la Quick Find Active, la Advanced Find View, la Associated View e la Lookup View. Le public view custom si creano dal view designer — Solutions, apri la tabella, area Views — oppure dall’app designer, che offre il drag and drop.
I filtri si modificano dal pannello delle proprietà della vista o, per condizioni più articolate, da Edit filters, che apre l’expression builder: Add row aggiunge una condizione, Add group un gruppo con operatore relazionale And (predefinito) oppure Or, Add related table filtra su una tabella correlata. Attenzione a un dettaglio che l’articolo segnala esplicitamente: su una tabella correlata, in un filtro di vista, Contains data è l’unico operatore condizionale utilizzabile. Salvi con Save, rendi disponibile agli utenti con Save and publish.
Main form: struttura e accesso per security role
Quando crei un nuovo form per una tabella il suo form type è Main, e alla prima apertura è identico al form chiamato Information. La struttura è gerarchica: ogni main form è composto da uno o più tab, ogni tab ha una o più section, ogni section contiene una o più colonne (form fields). Il percorso è New form > Main form > Create; per partire da un form esistente usi Save a copy dalla command bar. Serve il ruolo System Administrator o System Customizer. Gli altri form type documentati sono Quick Create, Quick View e Card.
L’accesso ai form si governa da Form settings, che raccoglie quattro aree: i security role del form, il form order, il fallback form e il form access checker. Per i security role scegli fra Everyone e Specific security roles. Il fallback form esiste perché ogni tabella deve poter mostrare un form a qualunque utente: è il form visibile a chi ha ruoli a cui non è stato associato esplicitamente nessun form. Due precisazioni che l’esame ama trasformare in distrattori: Quick Create, Quick View e Card non possono essere assegnati a security role, e il form order decide quale form appare per primo, non chi può vederlo.
La sicurezza di Dataverse non sta sotto /power-apps/
Qui c’è la trappola documentale: viste e form vivono nel docset di Power Apps, ma la sicurezza dei dati è documentata sotto /power-platform/admin/. Un security role raccoglie privilegi di tabella — Create, Read, Write, Delete, Append, Append to, Assign, Share — e ciascun privilegio ha un access level che stabilisce quanto in profondità nella gerarchia l’utente può esercitarlo: Organization, Parent: Child Business Unit, Business Unit, User, None. Un utente può avere più ruoli e i privilegi sono cumulativi.
La gerarchia è fatta di business unit: la root business unit è il livello più alto, ogni BU ha un solo padre e può avere più figli, e ogni utente appartiene a una e una sola business unit. I team aggiungono flessibilità: un owner team possiede record e ha security role assegnati; un access team non possiede record e non ha security role assegnati — i record gli vengono condivisi e il team riceve diritti di accesso (Read, Write, Append); esistono poi i Microsoft Entra group team, di tipo Security o Office. La condivisione di una riga avviene dall’utente finale con Share sulla command bar, ma chi riceve la condivisione deve comunque avere l’accesso basic concesso dall’amministratore.
L’articolo su come viene determinato l’accesso a un record descrive due controlli in sequenza: prima il privilege check, poi l’access check, che può essere superato per ownership, role access, shared access o hierarchy access. Sotto tutto questo si innesta la column-level security: attivi Enable column security in Advanced options sulla colonna, poi assegni uno o più column security profile (in Users + permissions) con i permessi Read, Read unmasked, Update e Create, eventualmente con una masking rule. Senza profili, solo il system administrator vede il valore; e la column-level security non si applica mai a chi ha il ruolo system administrator.
Nascondere una vista non nega un dato
È la distinzione che l’esame verifica. Puoi limitare una public view a determinati ruoli con View settings e l’opzione Specific security roles: l’effetto è che gli altri utenti non trovano quella voce nel view selector. Ma la stessa pagina è netta: “Having access to a particular view doesn’t mean you also have access to the data that’s available in the view”. L’accesso al dato resta governato dai privilegi del security role, e le viste mostrano soltanto i record a cui l’utente ha già accesso. Non solo: quel filtro agisce sul selettore della table list view, mentre le viste continuano a comparire nei subgrid e negli associated grid, e l’utente può raggiungerle da Manage and share views. Se devi impedire la lettura di un dato, agisci sui privilegi, sulla business unit o sulla column-level security; la vista e il form sono superfici di presentazione, non barriere.