Una model-driven app è un’applicazione che si costruisce a partire dai dati: definisci il modello in Microsoft Dataverse (tabelle, colonne, relazioni, business logic) e la piattaforma genera un’interfaccia responsive e coerente. A differenza di una canvas app, non disegni pixel per pixel: componi componenti e lasci che il rendering sia gestito da Dataverse. Per PL-400 devi saper scegliere il componente giusto per ogni esigenza e sapere dove collocare la logica.

Anatomia di una model-driven app

L’app si assembla nel modern app designer e ha come colonna vertebrale la site map (navigazione): definisce Area → Group → Subarea, dove ogni subarea punta tipicamente a una tabella, a un dashboard o a una URL. Gli altri componenti sono legati alle tabelle incluse nell’app:

  • Form: la superficie di data-entry. I tipi principali sono:
    • Main form — la vista completa del record, con tab, section, sottogriglie e controlli. Supporta più form per tabella con form order e security roles per mostrare layout diversi a ruoli diversi.
    • Quick View form — pannello read-only che mostra campi di un record correlato (es. dati dell’Account su un form Contact) senza aprirlo.
    • Quick Create form — form snello per creare rapidamente un record dal comando + New o inline.
    • Card form — usato nelle viste responsive/mobile.
  • View: query salvate sui dati (colonne, filtri, ordinamento). Distingui system view (Public, Lookup, Associated, Quick Find) dalle personal view create con Advanced Find. La Quick Find view definisce quali colonne sono ricercabili.
  • Chart e Dashboard: visualizzazioni aggregate; i dashboard combinano chart, view e (nella versione interattiva) stream filtrabili.

Personalizzare la command bar

La command bar è la barra dei comandi che appare sopra form e view. Oggi lo strumento raccomandato è Power Apps command designer con logica scritta in Power Fx: per ogni comando definisci l’azione (OnSelect) e la visibility tramite una formula che restituisce true/false. Puoi differenziare il comportamento per location (Main grid, Subgrid, Form, Associated view) e sfruttare oggetti come Self.Selected.Item per agire sul record selezionato.

Il classic ribbon (Ribbon Workbench / customization XML RibbonDiffXml) resta necessario quando il command designer non basta: Enable Rules e Display Rules complesse, dipendenze da parametri custom, o comandi ereditati. In esame, se lo scenario chiede logica di abilitazione avanzata non esprimibile in Power Fx, la risposta è il ribbon classico; per la maggior parte dei casi nuovi, invece, è il command designer.

Model-driven vs canvas app

Scegli model-driven quando l’app è data-centric, gira su Dataverse, richiede processi strutturati, relazioni complesse, sicurezza a livello di riga/colonna e un’esperienza standardizzata (es. gestione casi, CRM). Scegli canvas quando serve controllo pixel-perfect del layout, un flusso task-specifico, integrazione con molte sorgenti dati eterogenee o UX molto personalizzata. Nota che puoi embeddare una canvas app dentro un form model-driven per ottenere il meglio dei due mondi.

Dove va la logica (nodo cruciale per PL-400)

La logica di form è locale al form:

  • Business rules: no-code, applicano condizioni (mostra/nascondi, obbligatorietà, valori di default) a livello di form o a livello di tabella (scope Entity). Girano client-side e, con scope Entity, anche server-side.
  • Client scripting (JavaScript + Client API): eventi OnLoad, OnChange, OnSave per validazioni e comportamento UI dinamico.

Questa logica non si applica se il dato entra da un’altra via (import, API, plug-in, Power Automate). La logica che deve valere sempre — vincoli di integrità, calcoli, validazioni di business riutilizzabili — va implementata a livello di piattaforma con plug-in (pipeline server-side) o calculated/rollup column, non nel form.

Trappole tipiche d’esame

  • Serve una validazione che valga per ogni canale (form, API, import) → plug-in server-side, non una business rule di form o JavaScript (che coprono solo la UI).
  • Mostrare campi di un record correlato in sola lettura senza aprirlo → Quick View form, non una sottogriglia né un altro Main form.
  • Creazione rapida da un lookup o dal comando +New → Quick Create form abilitato sulla tabella; se manca, il pulsante non compare.
  • Comando visibile solo per certi record/ruoli → visibility in Power Fx nel command designer; ricorri al classic ribbon solo per Enable/Display Rule non esprimibili in Power Fx.
  • App che richiede layout pixel-perfect o molte sorgenti dati eterogenee → canvas app (o canvas embedded nel form), non model-driven.