Automatizzare i processi con Approvals

Il connettore Approvals di Power Automate incapsula il pattern “richiesta → decisione → azione” senza costringerti a costruire tabelle di stato o email manuali. L’azione chiave è Start and wait for an approval, che sospende il flow finché gli approvatori non rispondono, poi restituisce l’esito in Outcome e i singoli voti in Responses. Come functional consultant devi saper scegliere il tipo di approvazione corretto in base al processo:

  • Approve/Reject – Everyone must approve (sequenziale o parallelo): richiede il consenso di tutti gli approvatori. Utile per gate di conformità dove ogni firma è obbligatoria.
  • Approve/Reject – First to respond: basta la prima risposta a chiudere l’istanza. Adatto a code di supporto o approvazioni “chi è disponibile decide”.
  • Custom Responses – Wait for all / Wait for one: sostituisci Approve/Reject con opzioni di dominio (“Rimborso totale”, “Rimborso parziale”, “Nega”), poi diramare con uno Switch su Outcome.

Sequential vs parallel

Il termine crea confusione all’esame. Il parallel approval invia la richiesta a tutti contemporaneamente (una sola azione con più assegnatari). Per un iter sequenziale — il manager approva, poi il direttore — servono più azioni Approval in cascata, oppure un loop che itera su una lista di approvatori. Non esiste un interruttore magico “sequenziale”: lo modelli tu con la struttura del flow. Ricorda che gli approvatori interagiscono da Outlook actionable messages, dall’app Teams Approvals o dal portale Power Automate, senza bisogno di licenze premium aggiuntive.

Child flow: riutilizzare la logica

Quando la stessa sequenza di azioni (calcolo IVA, notifica, logging) ricorre in più automazioni, la incapsuli in un child flow richiamato dai flow “padre”. Questo evita duplicazione e centralizza la manutenzione.

Requisiti tecnici che l’esame verifica sempre:

  • Il child flow deve risiedere nella stessa solution del flow chiamante (i child flow non funzionano al di fuori delle solutions).
  • Deve usare il trigger manually run a flow (Power Apps / trigger manuale), definendo esplicitamente i parametri di input.
  • Restituisce dati al padre tramite l’azione Respond to a Power App or flow, che dichiara i parametri di output.
  • Il padre lo invoca con Run a Child Flow, passando gli input e leggendo gli output come token dinamici.

Attenzione al contesto di connessione: i child flow, per impostazione predefinita, girano con le connessioni dell’autore (“run-only”), quindi vanno gestite le autorizzazioni condivise.

RPA con Power Automate Desktop

Quando un sistema non espone API né connettori (un gestionale legacy, un terminale mainframe, un sito senza servizio web), l’integrazione a livello di dati è impossibile e devi ricorrere alla Robotic Process Automation. Power Automate Desktop (PAD) simula l’interazione umana: apre l’applicazione, legge campi via UI elements o image recognition, digita, clicca, estrae dati da PDF o Excel.

Attended vs unattended

La distinzione è centrale e determina licenze e scenari:

  • Attended: il bot viene avviato da un utente e gira sulla sua macchina mentre la persona è presente (spesso condividendo lo schermo). Ideale per attività che affiancano l’operatore — ad esempio compilare più portali partendo da un unico input. Incluso nel piano Power Automate con attended RPA.
  • Unattended: il bot gira in autonomia su una macchina virtuale, senza sessione utente interattiva, tipicamente schedulato o innescato da un cloud flow. Serve per elaborazioni batch notturne ad alto volume e richiede la licenza unattended RPA add-on.

Il ponte tra mondo cloud e desktop è il connettore Desktop flows: un cloud flow (magari partito da un’approvazione) chiama il desktop flow passando input e ricevendo output, orchestrando così processi ibridi API + UI.

Trappole tipiche d’esame

  • Un child flow richiamabile non parte / non è visibile in “Run a Child Flow” → deve stare dentro una solution e usare il trigger manually run a flow con input espliciti e output via Respond to a Power App or flow. Un flow fuori solution non è chiamabile come child.
  • Serve che il rimborso sia “Totale/Parziale/Nega”, non Approve/Reject → usa Custom Responses e dirama con uno Switch su Outcome, non due approvazioni Approve/Reject in cascata.
  • Basta una sola risposta per procedere → tipo First to respond; se invece tutti devono firmare, Everyone must approve (Wait for all).
  • Il gestionale legacy non ha API né connettore → Power Automate Desktop (RPA), non un custom connector: senza endpoint non c’è nulla da connettere.
  • Automazione batch notturna, nessun utente loggato → unattended desktop flow (richiede l’add-on). Se un operatore deve essere presente e avviarla, è attended.