Tre famiglie di trigger, e la domanda che le separa

Ogni cloud flow comincia da un trigger, che la documentazione definisce come l’evento che avvia il flow. Power Automate riassume la scelta in una riga sola: i trigger possono partire automaticamente, in modo istantaneo o manuale, oppure su pianificazione. Da lì derivano i tre tipi di flow che il portale ti fa scegliere quando parti da zero: Automated cloud flow, Instant cloud flow e Scheduled cloud flow.

Un flow automated reagisce a un evento in un servizio collegato: l’esempio della doc è il trigger When a new email arrives (V3) del connettore Office 365 Outlook. Un flow instant parte quando una persona preme qualcosa, tipicamente con Manually trigger a flow. Un flow scheduled usa il trigger Recurrence, dove configuri Time zone, Start time nel formato YYYY-MM-DDTHH:MM:SSZ e, a seconda della frequenza, On these days, At these hours e At these minutes.

La domanda che risolve la scelta non è quale trigger conosci meglio, ma chi decide che è il momento: il sistema di origine, una persona, o l’orologio.

Sotto questa classificazione ne esiste una seconda, meno visibile e più insidiosa. La guidance Optimize Power Automate triggers distingue polling triggers e webhook triggers: il primo interroga il servizio a intervalli regolari, il secondo si registra presso il servizio e riceve la notifica quando l’evento accade. La differenza si vede quando spegni e riaccendi il flow. Il polling trigger riprende da dove era rimasto e lavora anche gli eventi arretrati, con il rischio di uno sciame di esecuzioni tutte insieme; il webhook non riceve nulla mentre è spento e riparte solo dai nuovi eventi, quindi niente coda ma eventi persi. Per capire quale hai davanti, la doc di troubleshooting suggerisce di aprire Code view (o Peek code nel designer classico) e cercare la sezione recurrence con l’elemento frequency: se c’è, è un polling trigger.

Trigger condition: la leva che risparmia esecuzioni

Il primo istinto sbagliato è far partire il flow sempre e filtrare dopo con un Condition. La doc lo dice esplicitamente: aggiungendo condizioni dentro il flow, il flow gira comunque e le chiamate contano come richieste API, avvicinandoti ai limiti. La strada documentata è la trigger condition, che si imposta selezionando il trigger, aprendo Settings e scegliendo + Add accanto a Trigger conditions.

Ogni trigger condition deve iniziare con il simbolo @. Se ne aggiungi più di una, per impostazione predefinita devono essere tutte soddisfatte; per renderne una opzionale serve la sintassi OR:

@or(test1, test2, test3)

L’effetto è quello che l’esame ama far calcolare: nell’esempio della doc, mille fatture che generano mille esecuzioni diventano cinquanta se la condizione filtra le sole fatture approvate. E la frase da ricordare è testuale: “If the trigger condition isn’t met, the flow isn’t triggered, and no run history is logged.” Nessuna riga nello storico, il che spiega perché un flow che sembra non essere partito può in realtà avere un trigger check skipped.

Se scrivere l’espressione a mano ti spaventa, la doc descrive una scorciatoia legittima: costruisci la condizione in un’azione Filter array, apri Edit in advanced mode, copi l’espressione nella trigger condition e poi cancelli l’azione. Sui dati Dataverse la stessa pagina consiglia in alternativa la proprietà di filtro OData.

Due impostazioni vicine completano il quadro. Concurrency control è disattivato per impostazione predefinita e permette di fissare il degree of parallelism; la doc avverte che è irreversibile, quindi va applicato con prudenza e possibilmente su un child flow. E attenzione a un comportamento controintuitivo: le espressioni usate negli input di un trigger vengono calcolate al salvataggio, quindi utcNow() viene congelato come valore fisso e non ricalcolato a ogni esecuzione.

Connettori: due tipi, e un tier che non è un tipo

Qui si concentra l’errore più comune. La pagina Connectors overview dice che i tipi di connettore sono due: Prebuilt, cioè predefiniti e usabili senza modifiche, e Custom, cioè costruiti da te per scenari su misura, come wrapper attorno a una REST API descritta da una definizione OpenAPI, da una Postman collection o partendo da zero.

Standard e Premium non sono tipi: sono i valori del filtro Tier nella connector reference, accanto a Release Status, Product e Publisher. Sono cioè una classificazione di licenza, non di natura tecnica. Lo prova la legenda stessa dell’icona premium, che indica un connettore Premium per Power Automate e Power Apps ma Standard per Azure Logic Apps: stesso connettore, tier diverso a seconda del prodotto.

Sul denaro la formulazione da tenere a mente è: “To access premium, on-premises, and custom connectors, you need a standalone Power Apps or Power Automate license.” Nota che i connettori on-premises, quelli che passano dall’opzione Connect using on-premises data gateway, stanno nella stessa frase.

E conta la licenza di chi invoca. La doc di troubleshooting spiega che un flow con trigger Manual richiede la connessione dell’utente che lo lancia, mentre con Recurrence il flow gira sulle connessioni del maker; e che se un flow usa connettori premium ogni utente ha bisogno di una licenza Power Automate Premium o Power Automate Process per modificarlo o avviarlo manualmente. Un flow condiviso che funziona per te e fallisce per il collega è quasi sempre questo, non un bug.

Che cosa verifica l’esame

Le domande su questo obiettivo sono quasi sempre scenari: ti descrivono un evento, un volume e un vincolo, e ti chiedono trigger e connettore. Tre confusioni tipiche da disinnescare. La prima è rispondere “connettore standard” o “connettore premium” quando la domanda chiede il tipo: i tipi sono prebuilt e custom. La seconda è mettere un Condition come prima azione quando lo scenario parla di ridurre esecuzioni o consumo di richieste: lì la risposta è trigger condition. La terza è ignorare la licenza dell’utente finale quando il flow viene condiviso o richiamato da un’app.