I cloud flow di Power Automate automatizzano processi che si estendono su più servizi cloud. In qualità di functional consultant devi saper scegliere il trigger giusto, comporre le azioni in modo efficiente e progettare una gestione degli errori robusta, tenendo sempre d’occhio il consumo di API request.

Trigger e struttura di base

Ogni flow parte da un solo trigger, che ne determina la natura:

  • Automated: reagisce a un evento (record Dataverse creato/modificato, email in arrivo, file caricato).
  • Instant: avviato manualmente o da un pulsante/canvas app/Copilot.
  • Scheduled: eseguito su ricorrenza temporale.

Nei trigger Dataverse (“When a row is added, modified or deleted”) scegli con cura scope (Organization, Business Unit, User), le colonne filtro e una filter expression OData: filtrare lato origine evita esecuzioni inutili e risparmia azioni.

Controlli di flusso

I controlli strutturano la logica:

  • Condition: ramo if/else su una singola valutazione booleana.
  • Switch: smista su più casi discreti in base a un valore, più leggibile di condition annidate.
  • Apply to each: itera su un array/collezione.
  • Do until: ripete finché una condizione diventa vera; imposta sempre limiti di count e timeout per evitare loop infiniti.
  • Scope: raggruppa azioni logicamente ed è il pilastro del pattern try/catch.

Espressioni

Il linguaggio Workflow Definition Language (WDL) fornisce funzioni per manipolare i dati inline, senza azioni aggiuntive. Le più usate: outputs(), body(), triggerBody(), coalesce(), if(), formatDateTime(), first(), filter(). Sostituire azioni “Compose” o rami condizionali con espressioni riduce il numero di step e quindi il consumo.

Gestione degli errori con Configure run after

Per default un’azione parte solo se la precedente ha avuto successo. Con Configure run after cambi questa dipendenza attivandola su is successful, has failed, is skipped, has timed out. Il pattern try/catch/finally si costruisce così:

  • Uno Scope “Try” con la logica principale.
  • Uno Scope “Catch” con run after impostato su has failed / has timed out / is skipped, che notifica o compensa l’errore.
  • Uno Scope “Finally” che gira in ogni caso (configure run after su tutti gli stati) per cleanup e logging.

Usa result() per estrarre gli errori delle azioni nello scope e la Terminate action per chiudere il flow con stato Failed, Cancelled o Succeeded in modo esplicito.

Connection references

Le connection references disaccoppiano il flow dalla connessione concreta. Il flow punta al connection reference, che a sua volta è associato a una connection specifica. In una soluzione questo consente ai solution import verso ambienti Dev → Test → Prod di rimappare le credenziali senza riscrivere il flow, appoggiandosi a environment variables e deployment pipeline. Includi sempre i connection reference nella stessa solution del flow.

Concurrency, paginazione e API request

Tre leve determinano prestazioni e consumo:

  • Concurrency control: sull’apply to each puoi attivare il parallelismo (fino a un grado impostato). Velocizza ma può creare race condition e superare i limiti dell’API a valle; disattivalo quando l’ordine conta.
  • Pagination: molti connettori restituiscono risultati paginati. Attiva la paginazione e imposta un threshold per recuperare tutti i record, evitando dataset troncati silenziosamente.
  • API request limits: ogni azione (incluse le iterazioni) consuma richieste conteggiate sui Power Platform request limits giornalieri per utente/licenza. Meno azioni = meno consumo e minor rischio di throttling.

Trappole tipiche d’esame

  • Scenario: un flow con apply to each annidati su migliaia di record va lentissimo e supera i limiti di richieste API → sostituisci l’iterazione con un filtro OData lato origine (Filter Query) o un’operazione batch/bulk, non con più concurrency: gli apply to each annidati moltiplicano le azioni ed esplodono il consumo.
  • Scenario: dopo l’import in Prod il flow fallisce con errore di connessione → devi usare le connection references incluse nella solution e rimapparle nell’ambiente target, non le connessioni hardcoded di Dev.
  • Scenario: serve eseguire un’azione di notifica solo quando quella precedente va in errore → usa Configure run after su has failed, non una Condition (la Condition non intercetta i fallimenti runtime).
  • Scenario: un “Get rows” restituisce solo 5.000 record su un totale maggiore → abilita la pagination e alza il threshold; il default limita l’output.
  • Scenario: un Do until senza uscita rischia il loop infinito → configura sempre i limiti di count e timeout.