Un cloud flow è un’automazione ospitata su Power Automate che orchestra logica di business fra Dataverse, Microsoft 365 e centinaia di connettori. Per lo sviluppatore PL-400 la scelta cruciale non è “come costruisco il flow”, ma quando un cloud flow è lo strumento giusto rispetto a una plug-in Dataverse, e come configurarne trigger ed error handling per evitare esecuzioni superflue.

Tipi di trigger

Ogni cloud flow inizia con un solo trigger che ne determina il modello di esecuzione:

  • Automated: parte da un evento (una riga Dataverse creata, una mail ricevuta). È il tipo dominante nell’automazione di business.
  • Instant: avviato manualmente dall’utente (pulsante, app Power Apps, menu contestuale). Adatto ad azioni on-demand come “invia questo record in approvazione”.
  • Scheduled: eseguito a intervalli ricorrenti (ogni ora, ogni notte). Ideale per batch, promemoria e sincronizzazioni periodiche.

Il connettore Dataverse

Il trigger When a row is added, modified or deleted è il cuore dell’integrazione con Dataverse. I parametri chiave sono:

  • Change type: Added, Modified, Deleted o combinazioni. Scegliere solo i tipi necessari riduce le esecuzioni.
  • Table name e Scope: lo scope (Organization, Business Unit, Parent: Child business unit, User) definisce quali righe, in base alla proprietà del record, fanno scattare il flow. Organization è il più ampio; restringerlo migliora efficienza e sicurezza.
  • Select columns (filtering attributes): elenco di colonne che, se modificate, avviano il flow. Su un update, se cambia una colonna non elencata, il trigger non parte. È lo strumento principale per evitare run inutili su modifiche irrilevanti.
  • Filter rows: un’espressione OData (statuscode eq 1) che filtra ulteriormente lato server.

Trigger condition

Oltre ai filtri nativi, ogni trigger espone una trigger condition: un’espressione booleana che deve valutare true perché il flow parta. È il presidio contro i loop infiniti: se il flow modifica la stessa tabella che lo attiva, senza una condizione che escluda gli update generati dal flow stesso (es. controllare un flag o modifiedby) si innesca una ricorsione. Trigger condition e filtering attributes insieme sono la risposta d’esame classica al problema dei run superflui.

Pattern comuni

Approvazioni

Il connettore Approvals (Start and wait for an approval) sospende il flow finché un approvatore non risponde, con supporto a First to respond, Everyone must approve e approvazioni custom. L’esito guida un ramo condizionale (approva/rifiuta). Essendo asincrono, il flow può restare in attesa per giorni.

Error handling con Configure run after

Ogni azione ha impostazioni Configure run after che ne definiscono l’esecuzione in base all’esito dell’azione precedente: is successful, has failed, is skipped, has timed out. Un’azione configurata per partire solo su has failed implementa un blocco catch (logging, notifica, compensazione). Combinato con lo Scope (raggruppamento di azioni tipo try/catch/finally), consente pattern robusti senza codice.

Cloud flow asincrono vs plug-in sincrono

Questa è la decisione architetturale centrale:

  • Un cloud flow è asincrono: il salvataggio del record ritorna subito e il flow viene accodato. La latenza tipica dall’evento all’avvio è dell’ordine di secondi (spesso pochi, ma non garantiti in real-time). Non può bloccare o annullare l’operazione originale.
  • Un plug-in registrato nella pipeline sincrona (stage Pre/Post-operation) esegue dentro la transazione Dataverse: può validare, arricchire dati e lanciare un’eccezione per annullare l’operazione, con risposta immediata all’utente.

Regola pratica: serve validazione real-time, rollback transazionale o coerenza forte → plug-in sincrono. Serve orchestrazione, integrazione con sistemi esterni, notifiche o approvazioni tollerando latenza → cloud flow (o plug-in asincrono / evento su Service Bus per carichi elevati).

Trappole tipiche d’esame

  • Update che rilancia lo stesso flow → loop infinito: la risposta è impostare una trigger condition (e/o filtering attributes) che escluda le modifiche generate dal flow stesso, non aumentare i timeout.
  • Il flow parte a ogni salvataggio anche per campi irrilevanti: usare Select columns / filtering attributes sul trigger Dataverse così che scatti solo quando cambiano le colonne d’interesse.
  • Serve impedire il salvataggio se i dati non sono validi: un cloud flow asincrono non può annullare l’operazione → scegliere un plug-in sincrono in Pre-operation.
  • Gestire il fallimento di un’azione senza fermare il flow: configurare l’azione di recupero con Configure run after su has failed, idealmente dentro uno Scope per un pattern try/catch.
  • “Deve avvenire in tempo reale” per l’utente: ricordare che i cloud flow asincroni hanno latenza di secondi e non sono adatti a scenari a bassa latenza garantita.