Chiamare un cloud flow da una canvas app
Il punto di contatto fra una canvas app e Power Automate è il Power Automate pane: la voce Power Automate nell’app authoring menu di Power Apps Studio, attiva per impostazione predefinita. Da lì si fa Create new flow (partendo da un template oppure da Create from blank) o Add a flow per riusare un cloud flow già presente nell’ambiente; i flow agganciati compaiono nella sezione In your app. Per aggiungere un flow esistente la doc chiede tre cose insieme: avere accesso al flow, poter vedere i flow che fanno parte della stessa solution, e che il flow abbia un trigger Power Apps.
L’invocazione è una formula, non una configurazione a parte. Su una proprietà di comportamento come OnSelect si scrive il nome del flow seguito da .Run():
PowerAppsbutton.Run()Con il pannello attivo, la formula già presente sulla proprietà viene preservata quando si aggiunge il flow; nell’esperienza classica invece l’aggiunta del flow cancellava la formula esistente, e bisognava copiarla prima e riattaccarla dopo. Quella esperienza classica va usata solo per il troubleshooting: la doc dichiara che sarà ritirata e non più disponibile. Due voci del menu … accanto al flow contano nella pratica: Refresh, obbligatorio dopo aver modificato il flow fuori da Power Apps Studio (altrimenti il flow può fallire anche in app già pubblicate), e Remove from app, che stacca il flow dalla app senza toccarlo nell’ambiente. Infine un avvertimento di sicurezza che vale come principio di design: gli argomenti che passano da Power Apps a Power Automate viaggiano come traffico di rete e possono essere intercettati, quindi i valori vanno validati dentro il flow.
Errori: prima il presupposto, poi le funzioni
Il comportamento descritto nella doc degli errori vale solo se è attiva la funzionalità Formula-level error management. È attiva per impostazione predefinita nelle app nuove, ma app vecchie possono averla spenta: si controlla in Settings > Updates > scheda Retired, verificando che Disable formula-level management sia disattivato. Questo è anche un prerequisito di Test Studio, quindi conviene trattarlo come il primo controllo da fare.
Le funzioni dedicate sono IfError, IsError, IsBlankOrError e Error. Dentro le formule di sostituzione sono disponibili il record FirstError e la tabella AllErrors (con i campi Kind, Message, Source, Observed, Details), e la categoria dell’errore si confronta con l’enum ErrorKind. Il pattern documentato è gestire il caso previsto e rilanciare gli altri:
IfError( 1/Value( TextInput1.Text ),
If( FirstError.Kind = ErrorKind.Div0, Blank(), Error( FirstError ) ) )Tre comportamenti sono facili da sbagliare. In una formula di comportamento concatenata l’esecuzione non si ferma al primo errore: la seconda Patch parte comunque, e per fermarla serve IfError con il terzo argomento. Anche ForAll non interrompe le iterazioni: al termine restituisce un errore che contiene tutti gli errori incontrati. E App.OnError non sostituisce l’errore come fa IfError, perché a quel punto l’errore è già avvenuto: serve a controllare come viene riportato e a registrarlo. Per le funzioni che modificano i dati (Patch, Collect, Remove, Update, SubmitForm e simili) esiste in più la funzione Errors, che restituisce gli errori delle operazioni precedenti.
Verificare: Test Studio e Live monitor
Test Studio è la soluzione low-code per scrivere, organizzare e automatizzare test UI end-to-end delle canvas app: si scrivono i test con espressioni Power Apps oppure si usa il recorder, e si organizzano in test cases (fatti di test steps) raggruppati in test suites. Dentro una suite i test case girano in sequenza e lo stato della app persiste fra uno e l’altro: la app non viene ricaricata all’inizio di ogni test case, quindi se il secondo test deve partire dalla schermata iniziale la navigazione va messa come primo step. Le verifiche si scrivono con Assert, disponibile solo in Test Studio, e Trace è un’espressione opzionale che aggiunge informazioni ai risultati tramite l’evento OnTestCaseComplete: i messaggi finiscono nella tabella Traces del record TestCaseResult, con le proprietà Message e Timestamp. I limiti dichiarati sono espliciti e vanno saputi: components, code components scritti con Power Apps Component Framework, nested galleries, media controls, colonne di tipo persona, i controlli non elencati nelle funzioni Select e SetProperty, la necessità che il formula-level error management sia attivo, e l’incompatibilità con la feature sperimentale di version control Git.
Lo strumento di diagnostica in esecuzione oggi si chiama Live monitor, e la sua documentazione non sta sotto le canvas app ma nella sezione maker generale, insieme a quella dei model-driven app: è un dettaglio utile perché nelle pagine restano residui del vecchio nome Monitor. Si apre da Advanced tools > Open live monitor, e la sessione si aggancia a quella di Studio; per la versione pubblicata si passa da Apps, dal menu accanto a Details si sceglie Live monitor e poi Play published app. Mostra uno stream di eventi con colonne come Category, Operation, Result, Status, Duration, Data Source, Control, Property, e selezionando un evento si aprono le schede Details, Formula, Request, Response. Per vedere le espressioni sorgente nell’app pubblicata serve l’impostazione Debug published app, che però peggiora le prestazioni per tutti gli utenti e va riaccesa solo per il tempo necessario. Anche l’output di Trace appare qui, ma Trace funziona solo nelle formule di comportamento.
Da app ad agente: agent builder
Da una canvas app si può generare un agente con agent builder: da Agents nel pannello di navigazione si sceglie Create an agent from an app, oppure da Apps si usa Create agent from app sulla command bar. Si descrive in linguaggio semplice il processo da automatizzare (o si parte da un suggerimento), e lo strumento usa i metadati della app e l’obiettivo dichiarato per generare istruzioni passo per passo, estrarre knowledge e trigger, e convertire le skill della app in azioni; Regenerate instructions rigenera il testo dopo aver corretto l’obiettivo. Dopo la creazione l’agente si modifica, si testa e si pubblica in Microsoft Copilot Studio. I prerequisiti includono un database Dataverse nell’ambiente, l’impostazione di tenant per la pubblicazione di copilot con funzionalità AI, e il blocco delle customizzazioni non gestite disattivato; fra i limiti: vale solo per le canvas app, solo nelle region dove sono disponibili gli agenti generativi di Copilot Studio, e senza una connessione alla sorgente dati le azioni non possono essere estratte.
Qui sta la confusione tipica che l’esame può sfruttare: agent builder non è il Copilot control né il custom Copilot nelle canvas app. Quelle due pagine sono documentazione prerelease di funzionalità in preview e in dismissione — non si possono più aggiungere a nuove canvas app, le app esistenti restano funzionanti per un periodo limitato ma alla fine non saranno più supportate, e la strada indicata è Microsoft 365 Copilot nelle canvas app. In uno scenario che chiede di trasformare il processo di una app in un agente riusabile, la risposta è agent builder più Copilot Studio, non un controllo da inserire nella schermata.