Azioni e connettori: che cosa sta dentro il flow

Un agent flow è deterministico: la documentazione dice che “The same input always produces the same output”. È fatto di un trigger e di almeno una action, e non va confuso con gli altri tre oggetti che gli stanno intorno. Un topic è un percorso conversazionale creato sull’agente; un tool è ciò che l’agente decide di invocare a runtime; una knowledge source è ciò che l’agente legge per formulare una risposta. Un agent flow diventa un tool soltanto quando lo aggiungi all’agente, e per riuscirci deve avere il trigger When an agent calls the flow e un’azione Respond to the agent.

Le azioni si dividono in quattro famiglie: AI capabilities, Human in the loop, Built-in tools e Connectors. Le prime tre restano nel perimetro della piattaforma; la quarta è il punto in cui il flow esce verso servizi esterni. Nel designer aggiungi un’azione con Insert a new action sotto la card che ti interessa, la cerchi nel pannello Add an action e ne compili i campi nella scheda Parameters.

I connettori Power Platform sono proxy o wrapper attorno a delle API, e si dividono in tre categorie che l’esame chiede di distinguere. Gli standard connectors, come SharePoint, sono inclusi in tutti i piani di Copilot Studio. I premium connectors sono disponibili solo su piani selezionati: un flow che ne usa uno può funzionare in sviluppo e rompersi in un ambiente licenziato diversamente. Un custom connector raggiunge qualunque API pubblicamente disponibile non coperta dai connettori esistenti; lo crei da Add a tool > New tool > Custom connector, ma la creazione avviene nel portale Power Apps, fuori da Copilot Studio. Attenzione: questi non sono i Copilot connectors, oggetto diverso documentato sotto Microsoft 365 Copilot.

Guardare cosa ha fatto: Overview, Activity, Analytics

Il Designer è solo una delle schede di un flow; le altre tre rispondono alla domanda “che cosa è successo”. Nella scheda Overview modifichi nome, descrizione e connessioni, vedi owner e co-owner e le esecuzioni più recenti, e puoi cancellare il flow o spegnerlo per impedirne il trigger.

La scheda Activity è il registro delle esecuzioni: mostra lo storico dei run, il loro stato e quanto è durato ciascuno. Selezionando un run lo percorri passo per passo nell’activity view per capire dove si è fermato. Puoi anche selezionare più run e fare resubmit, oppure annullare quelli ancora in corso: è il gesto operativo tipico dopo un guasto transitorio risolto a monte.

La scheda Analytics dà la lettura aggregata: numero di esecuzioni, failure rate e trend nel tempo. Qui serve prudenza, perché la doc elenca limiti espliciti: i run compaiono nelle visualizzazioni con ritardo, le metriche di analisi dei run esistono solo per i solution flow, e i numeri possono divergere da quelli di Activity per differenze di fonte dati e refresh. Per dimostrare che un singolo run è avvenuto l’autorità è Activity, non Analytics. Prima del monitoraggio c’è comunque il controllo statico: il Flow checker elenca tutti gli errori del flow, e un flow con errori non si può pubblicare.

Quando fallisce: run after, retry, terminate

Il comportamento in caso di guasto si configura per singola azione. Le impostazioni Run after permettono di specificare che cosa deve succedere se un’azione fallisce, va in timeout, viene saltata oppure riesce: sono quattro esiti distinti, non due, ed è da qui che nascono i rami di gestione errore. Il pattern raccomandato raggruppa le azioni in scope, con uno scope “Try” che contiene la logica e uno scope “Catch” configurato per eseguire quando il Try fallisce; dentro il Catch si legge l’errore filtrando l’output della funzione result().

Il Retry policy vive nelle impostazioni dell’azione e agisce prima, sui guasti transitori di rete o di servizio: intervalli fissi o esponenziali, con intervallo iniziale e numero massimo di tentativi. La doc preferisce esplicitamente la strategia esponenziale. Il ramo di Run after si attiva invece sull’esito finale, cioè dopo che i retry sono esauriti: non sono alternative, sono due livelli. Per fermare tutto c’è l’azione Terminate, a cui assegni uno stato, per esempio “Failed”, e un messaggio. Per la diagnosi la funzione workflow() restituisce i metadati del run, che con Parse JSON e Compose diventano il link diretto all’esecuzione:

https://make.powerautomate.com/environments@{body('Parse_JSON')?['tags']?['environmentName']}/flows@{body('Parse_JSON')?['tags']?['logicAppName']}/runs@{body('Parse_JSON')?['run']}

Due guasti da riconoscere a colpo d’occhio. Una risposta troppo grande di un connettore fa fallire la richiesta con 400 Bad Request, e si risolve filtrando i dati dai parametri di input dell’azione, sotto Advanced inputs. L’errore FlowActionBadRequest in un canale come Teams indica invece un disallineamento fra lo schema di input o output del flow e quello che l’agente si aspetta: la cura è Refresh sul nodo Action, verifica dei parametri e nuova pubblicazione dell’agente.

Solution-aware: perché conta al rilascio

Gli agent flow sono componenti di solution, e da questo derivano bozze, versioning, export, import e personalizzazione. Al rilascio devi tenere separati tre oggetti che si somigliano solo nel nome. Una connection reference è un componente di solution che punta a una connessione, cioè alla credenziale: le operazioni di un solution-aware flow si legano alla connection reference e non direttamente alla connessione, e in import si fornisce una connessione per tutte le connection reference così che i flow possano essere attivati. Una environment variable trasporta invece un valore di configurazione che deve cambiare fra dev, test e produzione; la doc chiarisce che non è la stessa cosa di una connessione, perché “a connection represents a credential or authentication required to interact with the connector”. Una variabile globale, infine, non riguarda il rilascio: è stato di conversazione dentro l’agente. Alla domanda su quale oggetto porti la credenziale fra gli ambienti la risposta è connection reference.