Le model-driven app sono uno dei due modelli di sviluppo di Power Apps (l’altro sono le canvas app). L’idea di fondo è ribaltare il punto di partenza: invece di disegnare prima l’interfaccia, si parte dal data model e la UI viene generata automaticamente a partire dalla struttura dei dati. Per questo si dicono “guidate dai dati”: prima definisci come sono fatte e come si relazionano le informazioni, poi l’app costruisce le schermate di conseguenza.
Fondamento: Dataverse
Una model-driven app richiede sempre Microsoft Dataverse come backend. Non è un’opzione: senza Dataverse non puoi costruirla. Dataverse è il data store strutturato della Power Platform, organizzato in tabelle (un tempo “entità”) con colonne tipizzate e relazioni tra tabelle.
I mattoni con cui componi una model-driven app sono i componenti definiti in Dataverse:
- Tables (tabelle): definiscono i dati (es. Account, Contact, Case).
- Forms (moduli): le schermate di dettaglio per creare e modificare un singolo record.
- Views (viste): elenchi filtrati e ordinati di record (griglie).
- Charts e dashboard: visualizzazioni aggregate dei dati.
- Business rules e business process flow: logica e processi guidati passo-passo.
- Site map: la navigazione dell’app, che raggruppa tabelle e pagine in aree e gruppi.
Modificando questi componenti cambi l’aspetto e il comportamento dell’app, senza disegnare pixel: il layout responsive è fornito dalla piattaforma.
Model-driven vs canvas app
Il confronto è centrale all’esame. Le due filosofie sono opposte:
| Aspetto | Canvas app | Model-driven app |
|---|---|---|
| Punto di partenza | UI (tela vuota) | Data model (Dataverse) |
| Controllo sul layout | Alto, pixel-perfect | Basso, generato dalla piattaforma |
| Data source | Molte (Dataverse, SharePoint, SQL, connettori…) | Solo Dataverse |
| Approccio | Design-first | Data-first |
| Punti di forza | Flessibilità grafica, UX su misura | Robustezza, scalabilità, dati relazionali |
In sintesi: con una canvas app hai il pieno controllo del design, “trascini” i controlli e scrivi formule (stile Excel/Power Fx) per governare l’esperienza. Con una model-driven app rinunci a quel controllo estetico fine in cambio di coerenza, robustezza e scalabilità su dati complessi.
Sicurezza nativa con i security roles
Un vantaggio decisivo delle model-driven app è l’integrazione nativa con i security roles di Dataverse. La sicurezza è definita a livello di dato: i security roles stabiliscono chi può leggere, creare, modificare o eliminare record, con granularità fino a tabella, colonna e riga (record ownership, business unit, gerarchie). L’app rispetta automaticamente questi permessi, senza dover ricostruire la logica di autorizzazione dentro l’interfaccia. In una canvas app, invece, gran parte del controllo d’accesso va gestita più manualmente.
Quando preferire una model-driven app
Scegli model-driven quando prevalgono:
- Processi complessi e strutturati, con più fasi guidate (business process flow), es. gestione di lead, casi di assistenza, ticket.
- Dati relazionali con molte tabelle collegate tra loro.
- Esigenza di scalabilità e di un modello dati robusto e condiviso.
- Necessità di sicurezza granulare basata sui ruoli.
- Scenari Dynamics 365, che sono costruiti proprio come model-driven app su Dataverse.
Scegli canvas quando conta soprattutto un’esperienza utente su misura, un layout specifico o l’uso di data source diverse da Dataverse.
Trappole tipiche d’esame
- “Serve un layout pixel-perfect con un design molto specifico” → canvas app. Se lo scenario enfatizza controllo grafico e UX personalizzata, non è model-driven.
- “Processo complesso, molte tabelle relazionali, sicurezza basata sui ruoli” → model-driven app. Parole come “relational”, “complex process”, “role-based security” spingono verso model-driven.
- “Model-driven app senza Dataverse” → impossibile. Le model-driven richiedono sempre Dataverse; se lo scenario usa solo SharePoint o SQL come sorgente, la risposta è canvas app.
- “Dobbiamo rispettare i permessi definiti a livello di record/tabella” → security roles di Dataverse + model-driven app. L’integrazione nativa con i security roles è il punto chiave, non una logica costruita nell’interfaccia.
- “La UI deve essere generata dai dati, con form e view standard” → model-driven app. L’espressione “data-driven / generata dai dati” identifica il modello model-driven, non quello canvas.