Anatomia dell’azione e dell’attesa
Un’approvazione in un cloud flow non è un’email: è un record creato in Microsoft Dataverse dal connettore che la reference dei connettori intitola Standard approvals e classifica come connettore Standard. Da qui i prerequisiti che l’articolo “Get started with Power Automate approvals” mette in cima: un database Dataverse e una licenza valida per creare flow. In un environment diverso da quello di default il database viene provisionato al primo run, quindi l’utente che esegue per primo un flow di approvazione deve avere un ruolo di amministratore in quell’environment; nell’environment di default il database viene creato automaticamente.
L’azione da cui si parte è Start and wait for an approval. I campi obbligatori sono Approval type, Title e Assigned To; Details supporta Markdown, mentre Item Link e Item Link Description portano l’approvatore all’oggetto da valutare. Assigned To accetta indirizzi email, User Principal Name (UPN) o id utente di Microsoft Entra ID, separati da punto e virgola e anche mescolati fra loro.
Il verbo che conta è wait. L’azione mette in pausa il run finché la risposta non arriva: chi approva può rispondere dall’email, dal centro approvazioni (Action items > Approvals, scheda Received), da una scheda adattiva in Microsoft Teams o dall’app mobile. Alla ripresa, l’azione espone fra gli altri Outcome, Response summary, Completion date e l’array Responses, i cui elementi contengono Approver response, Approver name, Comments, Request date e Response date. Sono questi i path documentati nel connettore:
outcome
responses.approverResponse
responses.commentsDall’esito al ramo: la Condition
L’esito non ramifica da solo. Dopo l’azione si aggiunge una Condition e si confronta il valore dinamico Responses Approver response con Approve usando l’operatore is equal to. I due rami si chiamano True e False nel nuovo designer, If yes e If no nel designer classico: dentro il ramo positivo si mettono le azioni di conferma (una notifica, l’aggiornamento della riga di origine), dentro l’altro quelle di rifiuto.
Attenzione a un dettaglio che la reference del connettore dichiara in modo esplicito parlando delle risposte valide “Approve” e “Reject”: These responses are case-sensitive. Scrivere approve in minuscolo produce un flow che compila, gira senza errori e prende sempre il ramo sbagliato. È un classico distrattore: la domanda descrive un flow che “non fa nulla quando l’approvatore approva” e la risposta non è un problema di permessi né di connessione.
Le tre forme documentate
Approvatore singolo. È il modello dell’articolo “Create and test an approval workflow with Power Automate”: trigger, Start and wait for an approval con un solo destinatario in Assigned To, Condition sull’esito, azioni nei due rami. È la forma da scegliere quando esiste un unico decisore.
Sequenziale. Qui la documentazione offre due strade e vanno tenute separate. Quella moderna è “Set up sequential approvals”: si sceglie il tipo Sequential Approval nella stessa azione Start and wait for an approval, si popola Assigned To – 1 e si aggiungono i passi successivi con Add new item. Il flow interpella il primo approvatore e passa al secondo solo se il primo approva. La pagina chiude con una limitazione secca: non è possibile assegnare lo stesso approvatore a passi diversi della stessa approvazione. L’altro articolo, “Manage sequential approvals with Power Automate”, costruisce lo stesso comportamento a mano, concatenando due azioni Start and wait for an approval separate da una Condition e recuperando il secondo approvatore con Get manager (V2) di Office 365 Users. Funziona, ma è il modello più vecchio: se una domanda parla di “sequential approval” come tipo di approvazione, il riferimento è al primo articolo.
Parallela. L’articolo “Create parallel approval workflows” usa la topologia del flow, non il tipo di approvazione: si seleziona Add a parallel branch e ogni ramo ospita la propria Start and wait for an approval con la propria Condition. I rami partono insieme e ciascuna decisione è indipendente dalle altre. Un passo aggiunto con il pulsante +New step in fondo al flow, invece, viene eseguito dopo che tutti i rami precedenti sono completati: è lì che si mette l’email riepilogativa.
Che cosa confondere non si deve
La confusione più costosa è fra tipo di approvazione e disegno del flow. Con più indirizzi in Assigned To e tipo Approve/Reject - Everyone must approve hai comunque una sola azione e un solo esito complessivo: le azioni successive girano quando tutti hanno risposto o al primo rifiuto. Con Approve/Reject - First to respond basta una risposta qualsiasi a chiudere la richiesta. I rami paralleli servono quando ogni approvatore deve avere una logica propria (email diverse, aggiornamenti su colonne diverse), non semplicemente quando gli approvatori sono più di uno.
Da ricordare infine due varianti e un limite. Create an approval (l’articolo la chiama Create an approval (v2)) crea la richiesta senza attendere, e Wait for an approval riprende più tardi partendo dall’Approval ID: è il pattern a due flow consigliato quando il processo può durare oltre 30 giorni, ed è anche l’azione su cui è supportata la cancellazione dalla scheda Sent. Sul fronte dei limiti, il connettore dichiara una soglia di throttling di 50 richieste di creazione approvazione per flow ogni 60 secondi, e i timestamp delle approvazioni sono sempre mostrati in UTC.