Approvazioni che non muoiono dopo 30 giorni.

Un flusso di Power Automate che si mette in attesa di un'approvazione ha una durata massima: superati i 30 giorni, l'esecuzione viene terminata dalla piattaforma. La conseguenza operativa è sottile e per questo pericolosa — la pratica non risulta respinta né bloccata con un errore evidente: semplicemente smette di esistere come processo in corso.

Nella pratica quotidiana i casi che sforano il mese non sono affatto rari. Un investimento che aspetta il consiglio successivo. Un contratto in trattativa. Una verifica documentale che dipende da un fornitore terzo. Una richiesta partita a inizio agosto. Sono esattamente le pratiche più importanti — quelle con più valore in gioco tendono ad avere anche i tempi di decisione più lunghi.

La differenza di fondo è architetturale. Un'automazione a flusso mantiene lo stato nell'esecuzione: finché quell'esecuzione vive, il processo esiste. Vector mantiene lo stato nella richiesta, che è un'entità persistente: non c'è nessuna esecuzione da tenere in vita, e quindi nessun orologio che scade.

Sarebbe comodo, per noi, dirvi di spegnere Power Automate. Sarebbe anche un cattivo consiglio. Power Automate fa molto bene ciò per cui è nato: automatizzare attività all'interno dell'ecosistema Microsoft, spostare file, aggiornare elenchi, reagire a eventi in SharePoint o Teams. È incluso nelle licenze che avete già e in azienda lo conosce più di una persona.

Quello che regge male è la parte lunga e umana: un'autorizzazione che deve restare aperta per settimane, avere un responsabile identificabile, un tempo massimo, una delega quando quel responsabile è assente, e una traccia che sopravviva alla ritenzione della piattaforma. Quella parte la fa Vector, e all'automazione a valle continua a pensarci Power Automate.

Nelle organizzazioni che hanno adottato presto il low-code, il timeout è il sintomo meno grave. Quello che si trova, dopo qualche anno, è un parco di decine o centinaia di app di approvazione: una per la richiesta di acquisto di una divisione, una per le trasferte di un'altra, una per gli accessi, una per le sostituzioni. Ognuna con il proprio elenco SharePoint alle spalle, la propria logica di instradamento ricostruita a mano e il proprio autore, che nel frattempo ha cambiato ruolo.

Preso singolarmente ogni pezzo funziona: è così che quel parco è nato, un problema risolto alla volta. I costi arrivano tutti insieme e più tardi.

• Nessun registro unico dei processi: nessuno sa con certezza quanti iter autorizzativi esistano davvero in azienda, né dove.
• La stessa regola riscritta ovunque: alzare una soglia di firma significa toccare ogni app che la contiene, sperando di non dimenticarne una.
• Nessun versionamento del processo: la modifica sostituisce la precedente, e ciò che valeva sei mesi fa non è più ricostruibile.
• Nessuno SLA coerente: il concetto di ritardo va reimplementato caso per caso, quindi in pratica quasi mai c'è.
• Nessuna analisi trasversale: non esiste un posto dove leggere quanto ci mette l'azienda ad autorizzare, perché i dati stanno in decine di elenchi separati.
• Manutenzione a carico di chi resta: ogni riorganizzazione si propaga a mano su tutte le app.

Vector affronta lo stesso bisogno dalla parte opposta: un solo motore, molte definizioni di processo. Le regole, gli SLA, i ruoli e il registro delle decisioni sono condivisi; ciò che cambia da un processo all'altro è il disegno del flusso. Il secondo processo costa una frazione del primo, e il ventesimo non aggiunge una ventesima applicazione da mantenere.

Come si arriva lì partendo da un parco già cresciuto — censimento, criteri di scelta e migrazione a processo singolo — è il tema della pagina su come consolidare le app di approvazione.

Il catalogo copre l'intero ciclo di vita di una richiesta, così potete agganciarvi al momento che vi interessa senza fare polling:

• workflow.request.created — la richiesta è stata creata
• workflow.request.submitted — è stata inviata e il processo è partito
• workflow.request.approved — è stata approvata
• workflow.request.rejected — è stata respinta
• workflow.request.completed — il processo si è concluso
• workflow.request.cancelled — la richiesta è stata annullata
• workflow.step.completed — uno step del processo è stato completato
• workflow.chain.triggered — è stato avviato automaticamente un processo a valle

Il payload ha un involucro stabile: identificativo dell'evento, tipo, istante in cui è avvenuto, dati della richiesta (con definizione e stato), attore che ha compiuto l'azione e un blocco di dati specifici dell'evento. Stabile significa che potete costruirci sopra senza che un aggiornamento vi rompa il parser.

Una parte dell'automazione a valle non ha bisogno di passare da uno strumento esterno. Se al termine di un processo ne deve partire un altro — dall'RDA approvata all'ordine, dall'assunzione all'attivazione degli accessi — il concatenamento dei workflow lo fa direttamente: la definizione dichiara quale processo avviare, a quali esiti, con quale iniziatore e se copiare i dati del modulo.

Con tre guardrail pensati per evitare i disastri classici dell'automazione: profondità massima della catena pari a tre, divieto di concatenare una definizione con sé stessa, e controllo di idempotenza sugli eventi di catena già emessi, così un riavvio non produce processi duplicati.

Un dettaglio che i team tecnici notano subito: le integrazioni di Vector passano da webhook HTTP standard e API JSON. Non ci sono connettori premium da licenziare per parlare con un sistema fuori dall'ecosistema Microsoft, e non serve un consulente certificato per collegare un gestionale.

Se volete vedere come si disegna il processo che poi emette questi eventi, la pagina sull'editor BPMN entra nel dettaglio; per un caso applicativo completo c'è invece l'iter di richiesta di acquisto.