La scelta del tipo di app non è un dettaglio di implementazione: è una decisione architetturale che condiziona data model, sicurezza, canali di erogazione e roadmap. In PL-600 la domanda ricorrente è “dato questo requisito, quale contenitore raccomandi e perché”. Non esiste un’app “migliore” in assoluto — esiste quella coerente con persona, complessità del data model e canale.

Le quattro opzioni e la loro natura

  • Model-driven app: metadata-driven, guidata dal data model in Dataverse. L’UI è generata dallo schema (tabelle, relazioni, form, view, business rule). È la scelta per scenari data-centrici e relazionali: molte tabelle collegate, processi strutturati, ruoli di sicurezza granulari, viste e dashboard configurabili. Accessibilità e responsività sono garantite dalla piattaforma. Meno controllo pixel-level sul layout.
  • Canvas app: task-centrica, con controllo totale del layout drag-and-drop. Ideale per flussi guidati, form mirati, un numero limitato di schermate e connessione a più data source (Dataverse ma anche SharePoint, SQL, API custom). Il prezzo della libertà è che accessibilità, coerenza e manutenzione dipendono dal maker.
  • Power Pages: sito web esterno per utenti anonimi o autenticati non licenziati (clienti, cittadini, partner). È l’unica opzione quando il canale è un portale pubblico su dati Dataverse, con table permissions e web roles per la sicurezza a livello di riga.
  • Agenti Copilot Studio: interfaccia conversazionale per self-service, deflection, orchestrazione di azioni via topic/plugin/connector. Non sostituisce l’app: la affianca come canale di ingaggio in linguaggio naturale, dentro Teams, sul sito o come agente autonomo.

Guidare la scelta con i vincoli

Data model come primo discriminante. Se il requisito descrive molte entità correlate, gerarchie, sicurezza per record e reporting, la risposta è model-driven su Dataverse. Forzare qui una canvas app significa ricostruire a mano navigazione, relazioni e sicurezza che la piattaforma offre gratis: è la trappola più penalizzata all’esame.

Persona e canale. Utenti interni licenziati con processi strutturati → model-driven. Operatore che compila un singolo modulo su tablet → canvas. Utente esterno senza licenza → Power Pages. Chi vuole “chiedere” invece di “navigare” → Copilot Studio.

Mobile-offline come vincolo, non optional. L’offline nell’app mobile Power Apps è supportato nativamente per le model-driven app (profili offline su Dataverse) e in modo distinto per le canvas app. Se la richiesta cita tecnici sul campo senza connettività, la capability offline va progettata all’inizio: incide sulla scelta del contenitore, sulle tabelle sincronizzabili e sul disegno delle relazioni. Scoprire il requisito offline ad architettura congelata impone rework costoso.

Accessibilità come requisito di conformità. Per scenari con obblighi WCAG (settore pubblico, grandi organizzazioni) la model-driven riduce il rischio perché eredita pattern accessibili. Con una canvas app l’accessibilità è responsabilità esplicita del team (ordine di tabulazione, AccessibleLabel, contrasto) e va messa a piano fin dal design.

Trade-off e composizione

Le opzioni non sono mutuamente esclusive. Un’architettura matura spesso combina: model-driven per il back-office, Power Pages per il self-service esterno, una canvas app embedded per un’esperienza guidata specifica, e un agente Copilot Studio come front-end conversazionale — tutti sullo stesso Dataverse come single source of truth. Il pilastro Operational Excellence del Well-Architected favorisce la configurazione model-driven (manutenibilità, ALM via solution) rispetto al codice; il pilastro Reliability premia il riuso dello schema centrale invece della duplicazione dei dati su più source. Valuta anche Security: table permissions/web roles su Power Pages e ruoli Dataverse sono più robusti del “security through obscurity” di una canvas app che nasconde controlli.

Trappole tipiche d’esame

  • Scenario data-centrico con molte tabelle correlate e sicurezza per record → raccomanda una model-driven app, non una canvas: la canvas duplicherebbe navigazione e sicurezza che i metadati offrono nativamente.
  • Tecnici sul campo senza connettività affidabile → progetta l’offline dall’inizio scegliendo model-driven con profilo offline (o canvas offline mirata); non trattare l’offline come feature aggiunta a posteriori.
  • Utenti esterni senza licenza Power Apps che accedono a dati Dataverse → Power Pages con table permissions e web roles, non una canvas/model-driven app condivisa via link.
  • Requisito di conformità all’accessibilità WCAG su UI complessa → prediligi la model-driven per ereditare i pattern accessibili; se scegli canvas, pianifica esplicitamente labeling e tab order.
  • Esigenza di self-service conversazionale e deflection dei ticket → agente Copilot Studio come canale aggiuntivo, non una nuova app UI; l’agente orchestra azioni sullo stesso Dataverse.