Leggere il requisito prima di aprire un designer

Ciò che l’esame misura non è “so costruire una canvas app”, ma “so riconoscere quando serve”. Conviene interrogare il requisito su quattro assi: chi lo usa, su quali dati, con quale interazione, e se il passaggio chiave è una regola deterministica o un giudizio su contenuto non strutturato.

Una model-driven app è la risposta quando i dati sono densi e l’utente deve muoversi fra record correlati: la doc le dice “especially well suited to process driven apps that are data dense”. Il vincolo però è duro: la tabella “Model-driven and canvas apps compared” indica come data platform “Dataverse only”, e senza un data model in Dataverse la app non esiste. In cambio accessibilità e responsività arrivano automatiche.

Una canvas app serve quando conta il layout, o quando i dati stanno altrove: stessa tabella, “Dataverse + many others using connectors”, controllo della UI “Full control”, ma responsività solo se la progetti. Il prezzo del controllo è che tutto ciò che la model-driven app ti regala lo devi costruire a mano.

Se non serve alcuna interfaccia ma qualcosa deve accadere, la risposta è un cloud flow. I tipi documentati sono tre: automated cloud flow, che parte da un evento; instant cloud flow, dalla selezione di un pulsante; scheduled cloud flow, da una pianificazione. Prima di scriverne uno passa dalla pagina “Apply business logic in Microsoft Dataverse”: una validazione di campo è una business rule, non un flow, e restano disponibili real-time workflows e actions.

Quando il passaggio richiede di interpretare testo libero - riassumere, classificare, estrarre entità, abbozzare una risposta - la risposta è un prompt, costruito nel prompt builder. Quando servono conversazione, percorsi non prevedibili e la scelta autonoma di quali strumenti invocare, allora serve un agente in Copilot Studio. Per materializzare tutto questo in un colpo solo esiste plans in Power Apps, generalmente disponibile, che da una descrizione in linguaggio naturale genera tabelle Dataverse, canvas app, model-driven app, siti Power Pages, flow e agenti Copilot Studio.

La domanda che conviene sempre: esiste già?

Nella doc il patrimonio di prima parte non è un elenco unico: va cercato in tre posti diversi.

L’Agent Library è il catalogo in stile marketplace di agent template pronti e di componenti riusabili, distribuito su Microsoft Marketplace. Contiene agenti completi come My Company Policy, Request Tracker o Know Your Customer, e distingue due tipi: custom agents, costruiti in Copilot Studio, e declarative agents, che estendono Microsoft 365 Copilot. Include anche reusable components - fra cui Research, Document Extraction e Content Synthesis - che si importano nell’environment e si richiamano da un topic con un nodo Call an action.

I prebuilt AI model di AI Builder coprono compiti chiusi e ripetitivi su documenti e testo: Invoice processing, Receipt processing, ID reader, Business card reader, Text recognition, Sentiment analysis, Key phrase extraction, Category classification, Entity extraction, Language detection, Text translation. Alcune voci portano l’etichetta (preview): apri la pagina invece di fidarti della memoria.

I prebuilt prompt sono la scorciatoia generativa: AISummarize, AISentiment, AIClassify, AIExtract, AIReply, AITranslate. Si usano nei low-code plug-in di Dataverse, nelle formule di Power Apps e in Power Automate, con un’eccezione che la doc segnala: AITranslate non si consuma nelle app e nei flow come gli altri cinque.

Infine gli agenti già impliciti nelle app. La pagina “Add agents to your model-driven app”, che è prerelease, distingue autonomous agents - supervisionati nell’agent feed e collegati tramite Power Apps MCP server - e app assistant agents. E “AI features overview” elenca capacità che l’utente ha già: assistenza al riempimento dei form, smart paste, row summaries, esplorazione dei dati in una view. Se il requisito è “riassumi il record”, potrebbe essere solo configurazione.

Estendere in ordine di costo crescente

La scala si percorre dal basso. Il gradino più basso è la configurazione: colonne, business rule, form, view. Sopra c’è Power Fx, il linguaggio low-code della piattaforma, che secondo la doc copre lo spettro dal no-code al pro-code “with no learning or rewriting cliffs in between”; le logiche riusabili non hanno pagine dedicate ma vivono nella proprietà App.Formulas, dove stanno named formulas, user-defined functions e user-defined types, e dove la ricorsione non è supportata. Un prompt si consuma proprio qui: lo aggiungi come sorgente dati e lo chiami per nome.

Set(risultato, 'Task identifier'.Predict(TextInput1.Text))

Sopra c’è il custom connector, “a wrapper around a REST API”, che si definisce da una OpenAPI definition, da una Postman collection o da zero, e serve solo quando fra i connettori prebuilt non c’è quello giusto. Attenzione alla tassonomia: la doc classifica i connettori in prebuilt e custom, mentre standard e premium sono tier di licenza, non tipi. Poi viene il code component costruito con Power Apps component framework, quando nessun controllo esistente rende l’esperienza richiesta. Poi il plug-in, e qui la doc è netta: “Use plug-ins when a declarative process doesn’t meet your requirement.” In cima Copilot Studio, per ciò che è davvero conversazionale o agentico.

Il criterio che l’esame verifica è la scelta del componente meno costoso che soddisfa il requisito, non del più potente: davanti a uno scenario risolvibile con una business rule, l’opzione con il plug-in è il distrattore. Ultima cautela sulle etichette: l’articolo sulle generative pages non porta banner di preview, mentre altre pagine le citano con “(preview)”. Ancora il discorso al comportamento e nomina la pagina, invece di dichiarare uno stato secco.