Anatomia di un flow: dove nasce l’automazione

In Power Automate ogni flusso parte da un trigger, l’evento che ne determina l’esecuzione. La scelta del trigger non è un dettaglio tecnico: definisce la categoria del flow, il modello di consumo e i limiti di throughput. Come functional consultant devi saper mappare un requisito di business (“quando arriva un lead, notifica il commerciale”) sul tipo di flow corretto, non solo farlo funzionare.

I flow si dividono in due grandi famiglie: i cloud flow, che girano nel servizio Power Automate, e i desktop flow, che automatizzano l’interfaccia utente sulla macchina (RPA).

Le tre tipologie di cloud flow

Automated (a evento)

Si avvia automaticamente quando si verifica un evento in un connettore: un record creato in Dataverse, un’email in arrivo, un file caricato in SharePoint. È il pattern più comune per l’integrazione tra sistemi e per l’automazione reattiva dei processi. Usalo quando la logica deve rispondere a un cambiamento di stato dei dati.

Instant (istantaneo)

Si avvia manualmente, su richiesta dell’utente: dal pulsante “Flow” nell’app mobile, da un pulsante in una model-driven app o canvas app, o tramite il trigger For a selected row. È la scelta giusta quando serve controllo umano — l’utente decide quando eseguire — e quando puoi passare parametri di input al momento del lancio.

Scheduled (schedulato)

Si avvia a intervalli ricorrenti definiti da un calendario (ogni ora, ogni notte, il primo del mese). Ideale per batch, sincronizzazioni periodiche, report ricorrenti e operazioni di pulizia. Non reagisce agli eventi: se il requisito è “tutte le sere alle 2:00 elabora gli ordini del giorno”, questo è il tipo corretto, non un automated.

Desktop flow (RPA)

Quando il sistema target non ha API né connettore — un gestionale legacy, un terminale, un’applicazione desktop — si ricorre ai desktop flow di Power Automate for desktop. Automatizzano click, digitazione e lettura schermo. Possono girare in modalità attended (con l’utente presente) o unattended (in background, tipicamente su un pool di macchine con licenza dedicata). Spesso un cloud flow orchestra e richiama un desktop flow per il passaggio “impossibile da API”.

I trigger Dataverse: create, update, delete

Il connettore Dataverse offre il trigger When a row is added, modified or deleted, con parametri architetturalmente rilevanti:

  • Trigger condition (Create / Update / Delete): scegli su quale operazione reagire. Puoi combinarle.
  • Scope: definisce quali record “vede” il flow in base alla proprietà/gerarchia:
    • User — solo i record posseduti dall’utente che ha creato il flow;
    • Business Unit — i record della business unit;
    • Parent: Child Business Unit — la BU e le sue figlie;
    • Organization — tutti i record dell’ambiente (scelta tipica per automazioni di sistema).
  • Select columns: elenca le colonne che, se modificate, fanno scattare il trigger. Con Update, se una colonna non elencata cambia, il flow non parte.
  • Filter rows (filter expression): una condizione OData che filtra ulteriormente (es. statuscode eq 1), riducendo esecuzioni inutili.

Quando usare cosa

  • Reagire a un cambiamento dati → automated con trigger Dataverse.
  • Azione decisa dall’utente su un record specifico → instant (For a selected row).
  • Elaborazione a orari fissi → scheduled.
  • Sistema senza API → desktop flow, orchestrato da un cloud flow.

Trappole tipiche d’esame

  • Trigger Update senza filtri → loop ricorsivo. Scenario: un flow su modified aggiorna una colonna dello stesso record, che riscatena il trigger all’infinito, esaurendo le API request e i limiti di throughput. Risposta giusta: restringi con Select columns (solo le colonne rilevanti) e/o una filter expression, così il flow non reagisce alle proprie scritture.
  • “Ogni sera alle 22:00” → Scheduled, non Automated. Un requisito basato sul tempo, non su un evento dati, richiede un flow scheduled (recurrence trigger).
  • “L’utente preme un pulsante nella model-driven app” → Instant. Il trigger corretto è manually trigger / For a selected row, non un automated su create.
  • Il flow deve agire su record di altri utenti → Scope Organization. Con Scope User vede solo i propri record; per coprire l’intero ambiente serve Organization.
  • Applicazione legacy senza connettore → Desktop flow (RPA). Se manca l’API, nessun cloud flow “puro” risolve: serve un desktop flow, eventualmente unattended e richiamato da un cloud flow.