I quattro tipi di form e a che cosa serve ciascuno
Quando apri l’area Forms di una tabella Dataverse e selezioni New form, la documentazione elenca quattro tipi, ognuno con uno scopo preciso. Il Main form è l’interfaccia principale con cui gli utenti leggono e modificano i dati di una riga. Il Quick create form è una versione essenziale ottimizzata per creare nuovi record e compare in un side panel, così l’utente non abbandona la schermata su cui sta lavorando. Il Quick view form non vive da solo: appare dentro un main form per mostrare dati aggiuntivi, in sola lettura, di una riga referenziata da una colonna lookup. Il Card form serve nelle view, per presentare le informazioni in formato compatto adatto agli schermi piccoli.
Le differenze che contano davvero sono nel comportamento, non nel nome. Solo ai main form si possono assegnare i security role: da Form settings scegli Security role e poi Everyone oppure Specific security roles. Quick Create, Quick View e Card non sono assegnabili ai ruoli. Sempre solo i main form hanno il concetto di fallback form, cioè il form che viene mostrato a chi non ha ruoli associati ad alcun form: senza fallback una tabella con più main form può lasciare un utente senza interfaccia. Il Form order invece decide quale form si apre per default quando ne esistono più di uno, e la doc insiste su un punto che l’esame ama trasformare in distrattore: l’ordine non stabilisce chi può vedere un form, quello lo fanno i security role.
Il quick view form ha una lista di limiti che vale la pena memorizzare: non permette di modificare i dati, non supporta i form script, non ha aree header, footer o navigation, e ha un solo tab a colonna singola in cui puoi aggiungere soltanto sezioni a colonna singola, colonne, subgrid e spacer. Il quick view control è legato a una colonna lookup e se quel lookup non è valorizzato il controllo semplicemente non è visibile.
Il form designer, i componenti e la subgrid
Il form designer offre un’anteprima WYSIWYG che si aggiorna mentre lavori. Le sue aree sono la Command bar con Save e Publish, la Form preview, i pane laterali Columns, Components, Tree view e Form libraries, il Property pane sempre disponibile, più Preview size switcher, Show hidden, Zoom slider e Fit to width. Il Tree view è lo strumento con cui selezioni una colonna nascosta: per default le colonne hidden non compaiono nell’anteprima.
I componenti si aggiungono trascinandoli dal pane Components, oppure selezionando una colonna e usando + Component nel property pane. Nella dialog di configurazione, sotto Show component on, le opzioni Web, Mobile e Tablet sono già selezionate: se un componente non deve comparire su un client, lo escludi qui. Con Get more components trovi controlli aggiuntivi nelle schede Built by Microsoft e Built by others.
La subgrid mostra in formato tabulare un elenco in sola lettura di record correlati o non correlati, dal quale l’utente può comunque creare o aprire una riga. Le proprietà da conoscere sono Show related records, che filtra il dropdown Table alle sole tabelle in relazione con quella corrente, Default view, Allow users to change view con le varianti Show all views e Selected views, Hide search box, Show chart only con Default chart, e Maximum number of rows, che accetta da 2 a 250 righe. Attenzione a Use available space: la doc dice che funziona solo con il legacy web client e non ha effetto su Unified Interface. Il componente Quick view, invece, si configura nella dialog Select quick view forms scegliendo Lookup Column, Related table e Quick View Form.
Le view: colonne, filtri, ordinamento e chi le possiede
Una view definisce quali colonne mostrare, in quale ordine, con quale larghezza, con quale ordinamento di default e con quali filtri di default. Ne esistono tre tipi. Le personal view appartengono a singole persone e sono visibili solo a loro se non le condividono; si creano con Create view dalla command bar dell’app e richiedono almeno accesso User sulle azioni della tabella Saved View. Puoi creare una personal view partendo da una system o da una public, mai il contrario. Le system view sono Quick Find, Advanced Find, Associated e Lookup: non compaiono nel view selector, non si usano nelle sublist di un form né come lista in una dashboard, e non si cancellano né si disattivano. Le public view sono quelle generiche accessibili dal view selector, riusabili nelle subgrid e nelle dashboard, e una di esse si designa con Set as default view.
Le colonne si aggiungono dal pannello Table columns, aperto con View column sulla toolbar; la scheda Related e il dropdown Row type permettono di portare nella view colonne di tabelle in relazione 1:N. Si rimuovono con Remove dal menu dell’intestazione, si spostano trascinando o con Move Right e Move Left, e si ridimensionano trascinando il bordo. La doc raccomanda di includere solo le colonne necessarie, perché molte colonne degradano le prestazioni di view e griglie, e di non mettere in view la colonna su cui la view filtra già.
Per i filtri hai due strade: Filter by direttamente sulla colonna, oppure Edit filters che apre l’expression builder, dove Add propone Add row, Add group e Add related table. And è l’operatore relazionale di default e puoi passare a Or; le condizioni selezionate si raggruppano con Make group e si sciolgono con Ungroup. Un vincolo tipico da domanda d’esame: con una related table dentro un filtro di view l’unico operatore utilizzabile è Contains data. L’ordinamento si imposta con Sort A to Z o Sort Z to A dal menu di colonna, oppure con Sort by per la colonna primaria e Then sort by per quelle successive, e si pubblica con Save and publish. Gli amministratori possono inoltre gestire le public view con i security role da View settings, scegliendo Specific security roles; le public view di default non sono assegnabili, e avere accesso a una view non implica avere accesso ai dati che mostra.
Il grid control e la trappola dei due articoli
Il Power Apps grid control è presentato come l’evoluzione del classico read-only grid: consente di visualizzare, aprire e modificare i record da view e subgrid, e aggiunge infinite scroll, nested grid, grouping, aggregation e personalizzazione. Il punto operativo è che aggiungerlo a una subgrid dal form designer non lo rende editabile: Enable editing parte da No e va configurato. Nello stesso elenco di proprietà Enable filtering e Enable sorting sono a Yes per default, mentre Enable grouping, Enable aggregation, Enable jump bar e Enable pagination partono da No; la nested grid si costruisce con Child items e Child items parent ID. Nota il vincolo incrociato: il grouping non è supportato quando la paginazione è attiva sulla griglia.
Qui si annida la confusione da evitare. Cercando in doc trovi due articoli distinti: quello del Power Apps grid control e quello del Power Apps read-only grid (deprecated), che documenta un controllo di sola lettura ormai deprecato. Le capacità di modifica inline, nested grid e aggregation appartengono al primo, non al secondo, e la tabella dei controlli disponibili elenca insieme a loro anche Editable grid (deprecated) e Read-only grid (deprecated). Su questo argomento l’esame verifica soprattutto la scelta corretta in scenario: dato un requisito, sai dire se serve un main form con subgrid, un quick create, un quick view legato a un lookup, una public view con filtro e sort, oppure la configurazione del grid control per abilitare la modifica inline. Se la domanda parla di modifica diretta nella griglia e le opzioni includono un controllo marcato deprecated, quella non è la risposta giusta.