Il flow checker vive in una pagina che si chiama “error checker”

Il primo strumento di diagnosi agisce prima ancora che il flow venga eseguito. Il flow checker è sempre attivo: la doc afferma che “The checker is always active, appearing in the command bar in the designer”. Nel designer è l’icona a forma di stetoscopio sulla command bar, e il pannello Flow checker si apre da solo quando salvi, se ci sono errori o warning. Quando il flow è pulito compare il messaggio No errors found.

Attenzione a un dettaglio che fa perdere tempo: la pagina che documenta il flow checker ha URL error-checker e nel sommario non esiste una voce intitolata “flow checker”. Se cerchi quel nome e non lo trovi, non stai scoprendo che la funzionalità è sparita: stai solo cercando nel posto sbagliato.

Il checker distingue errors da warnings: i primi impediscono il salvataggio, i secondi segnalano rischi di performance o affidabilità. I codici di design-time ricorrenti sono FlowCheckerError (campo obbligatorio vuoto o connessione non selezionata), MissingRequiredProperty, DuplicateActionName e InvalidTemplate, che copre gli errori di sintassi nelle espressioni. Su quest’ultimo c’è una trappola classica: nei riferimenti gli spazi del nome azione diventano underscore, quindi un’azione chiamata “Get item” si scrive outputs('Get_item') e non outputs('Get item').

La cronologia delle esecuzioni e i codici di errore

Se il flow è salvato ma non si comporta come vuoi, si passa alla 28-day run history nella pagina di dettaglio, dove per default vedi le colonne Start, Duration e Status; la vista All runs mostra anche i controlli del trigger saltati. Con Edit columns aggiungi colonne mappate sugli output del trigger: su un flow che gira spesso è l’unico modo pratico per isolare la run che ti interessa.

Aperta la run, l’azione fallita ha un’icona rossa: espandila e confronta Inputs e Outputs con quello che ti aspettavi. Se il flow è tutto verde ma il risultato è sbagliato, il problema è di logica, e la doc suggerisce di inserire azioni Compose nei punti chiave per ispezionare i valori intermedi. Corretta la causa, Resubmit rilancia la stessa run con gli stessi dati di input.

Come si leggono i codici più comuni:

  • 401 e 403: autenticazione o permessi. Con 401 si va in Connections e si usa Fix connection; con 403 si controllano anche le policy DLP.
  • 400 e 404: configurazione dell’azione errata, oppure risorsa inesistente, rinominata o cancellata.
  • 429: throttling. Aggiungi un ritardo prima dello step, oppure abilita il retry con backoff nelle impostazioni dell’azione.
  • 500 e 502: la doc li definisce guasti temporanei o transitori, quindi la mossa giusta è Resubmit.

Ai proprietari arrivano anche i repair tips via email, con le sezioni What happened e How do I fix e il pulsante Fix my flow. Nel nuovo designer c’è troubleshoot in Copilot, che produce un riassunto leggibile dell’errore. Per lo storico lungo, i solution cloud flow scrivono ogni esecuzione nella tabella FlowRun di Dataverse, con Status a valori Success, Failed o Cancelled e una retention di 28 giorni per default; la doc avverte però che quello stream non è transazionale, mentre la run history del portale sì.

Non parte, oppure parte troppe volte

Una run history vuota significa che il trigger non è mai scattato. Le cause documentate: trigger schedulato con data di inizio nel futuro, trigger condition che filtra proprio gli eventi di test, connessione rotta, flow spento o sospeso. Un flow che viola una policy DLP viene sospeso e non parte: la doc suggerisce di provare a salvarlo, perché è il flow checker a segnalare la violazione. Ricorda anche che i trigger a evento usano un intervallo di polling e non sono istantanei.

Il caso opposto, le esecuzioni duplicate, ha una spiegazione che vale la pena memorizzare: la doc la attribuisce al design “at-least-once” di Azure Logic Apps. La risposta corretta non è disattivare i retry, ma progettare il flow idempotente, per esempio verificando che il record non esista già prima di crearlo. Restano due leve: le trigger conditions, per non partire affatto quando non serve, e la concurrency control nelle impostazioni del trigger, spenta per default, che fissa il grado di parallelismo. Qui la confusione tipica costa cara: la doc dice che la concurrency control è irreversibile e che per rimuoverla devi creare un nuovo flow.

Governare il fallimento: run after, retry, timeout, static result

Nella scheda Settings di ogni azione ci sono tre impostazioni che cambiano il comportamento in caso di errore. Run After decide se l’azione successiva parte quando la precedente riesce, fallisce, va in timeout o viene saltata: è il meccanismo con cui si costruisce lo schema Try/Catch a base di Scope. Nota di documentazione utile: “Configure run after” non ha una pagina propria, vive nelle linee guida sull’error handling e nella tabella delle impostazioni del designer.

Retry Policy gestisce i guasti intermittenti; il default è una policy a intervallo esponenziale, con un numero di tentativi che dipende dal profilo di performance e dalla presenza di connettori premium, e puoi sostituirla con una policy fissa o con nessuna. Action Timeout genera un fraintendimento frequente: la doc precisa che imposta la durata massima fra retry e risposte asincrone, e che “This setting doesn’t change the request timeout of a single request”.

Per il mocking in test si usa la scheda Testing dell’azione, con il toggle Enable Static Result: con i risultati statici attivi l’azione viene trattata come riuscita senza essere davvero eseguita, oppure forzata a rispondere con un codice specifico per vedere come reagisce il flow. Quando sono attivi, l’etichetta del toggle diventa Disable Static Result. È lo strumento che l’esame si aspetta quando la domanda chiede come collaudare un ramo di errore senza toccare il sistema a valle.