Automatizzare un’operazione non significa sempre eseguirla senza intervento. Se un’azione può modificare dati importanti, applicare una condizione commerciale, trasferire fondi o avere effetti su terzi, potrebbe essere necessario attendere l’autorizzazione di una persona. Un flusso di approvazione umana nelle automazioni PHP consente di applicare questo controllo senza trasformare il processo in una catena informale di messaggi e decisioni difficili da ricostruire.
La chiave non è aggiungere un pulsante «Approva», ma definire che cosa viene proposto, chi può decidere, su quali informazioni, per quanto tempo e che cosa accade dopo. Il sistema deve poter spiegare ogni stato ed evitare che un’approvazione vecchia o duplicata esegua un’azione diversa da quella sottoposta a revisione.
Decidere quando sospendere un’operazione
Una revisione successiva serve a individuare i problemi dopo che l’azione è stata eseguita. Un’approvazione preventiva, invece, ne blocca l’esecuzione finché non viene presa una decisione. È opportuno richiedere un’autorizzazione quando l’impatto potenziale, la difficoltà di annullare l’azione o l’incertezza superano il livello accettato per l’automazione.
Valuta ogni operazione con domande concrete: può modificare un dato difficile da recuperare? Ha effetti su denaro, diritti, accessi o impegni con i clienti? Esiste una regola verificabile che consenta di eseguirla in autonomia? Quali danni causerebbe un errore e quanto tempo c’è per rispondere? Un’operazione ordinaria, reversibile e circoscritta potrebbe essere eseguita automaticamente e registrata per una revisione. Un’azione eccezionale o ad alto impatto può richiedere un’autorizzazione prima dell’esecuzione.
Evita di applicare il controllo umano a tutto per impostazione predefinita. Una coda sovraccarica provoca ritardi e favorisce approvazioni meccaniche. Definisci soglie ed eccezioni e misura le richieste in attesa, i tempi di attesa, i rifiuti e le scadenze per individuare le regole da modificare. La decisione deve basarsi sul rischio effettivo, non solo sulla possibilità tecnica di eseguire un’operazione.
Definire che cosa viene proposto e che cosa può essere autorizzato
Chi effettua la revisione deve comprendere l’effetto dell’operazione, non decifrare un oggetto interno di PHP. Mostra il valore attuale e quello proposto, il motivo, l’origine dei dati, le conseguenze rilevanti e ogni limitazione. Se la decisione dipende da una regola, mostra le spiegazioni necessarie per applicarla. Nascondi o proteggi i dati personali non necessari.
Separa il comando di proposta dall’autorizzazione. La proposta descrive l’azione e i suoi parametri; l’autorizzazione consente di eseguire quella specifica proposta. Non deve concedere permessi generali né consentire a chi approva di modificare i parametri senza che ciò sia visibile. Se sono necessarie modifiche, chi effettua la revisione può richiederle; il sistema crea una proposta aggiornata che dovrà passare attraverso le regole di autorizzazione applicabili.
Applica il principio del minimo privilegio: limita chi può creare, autorizzare, rifiutare o annullare le proposte e verifica questi permessi sul server a ogni transizione. Quando il rischio lo giustifica, impedisci a chi propone un’operazione di autorizzarla autonomamente. Questa separazione deve essere implementata nella logica dei permessi e non deve basarsi soltanto sul nascondere i pulsanti nell’interfaccia.
Modellare stati e transizioni espliciti
Rappresenta il processo come una macchina a stati. Un insieme iniziale utile può includere pending, approved, executing, rejected, changes_requested, expired, cancelled e executed. Una proposta in attesa può essere approvata, rifiutata, annullata o scadere; una proposta approvata può passare all’esecuzione solo se è ancora valida; una proposta in esecuzione può terminare come eseguita o tornare a uno stato recuperabile se si stabilisce che non ha prodotto effetti. Una proposta eseguita non può essere approvata di nuovo.
Salva lo stato attuale insieme a una cronologia immutabile di decisioni e transizioni. Registra l’identificatore della proposta, lo stato precedente e quello nuovo, l’autore dell’azione, la data e l’ora, il motivo e il riferimento alla versione dei dati esaminati. Non sovrascrivere la cronologia quando aggiorni il record: è necessaria per verificare che cosa è accaduto e diagnosticare i problemi.
In PHP, centralizza le transizioni in un servizio di dominio o in un componente equivalente. Evita che controller diversi modifichino direttamente lo stato con aggiornamenti generici. Convalida la transizione e i permessi all’interno di una transazione, quando opportuno, e rifiuta le azioni incompatibili con lo stato attuale. Questa struttura riduce gli errori di concorrenza e facilita il test delle regole senza dipendere dall’interfaccia.
Evitare approvazioni obsolete ed esecuzioni duplicate
I dati possono cambiare mentre una proposta è in attesa. Una persona non deve autorizzare una condizione che non corrisponde più all’operazione da eseguire. Quando crei la proposta, salva una versione, la data di aggiornamento o un’impronta dei campi rilevanti. Al momento dell’approvazione, confrontala di nuovo con lo stato corrente.
Il controllo al momento dell’approvazione non basta: i dati possono ancora cambiare prima che l’operazione venga applicata. Subito prima dell’esecuzione, confronta nuovamente la versione o l’impronta corrente con quella approvata. Se differiscono, interrompi il processo, invalida l’autorizzazione per quella proposta e richiedi una nuova decisione sui dati aggiornati. A seconda del rischio, puoi mostrare le differenze e richiedere una conferma esplicita, ma non riutilizzare automaticamente l’approvazione precedente.
Una scadenza limita il periodo durante il quale la decisione è considerata valida. Alla scadenza, contrassegna la proposta come scaduta e richiedi una nuova autorizzazione per proseguire. Ogni nuovo tentativo deve verificare che l’autorizzazione sia ancora valida; non riutilizzare mai un’autorizzazione scaduta per riprendere o ripetere l’esecuzione.
L’approvazione deve riferirsi a una proposta identificabile e non essere un’autorizzazione riutilizzabile. Per evitare che due worker concorrenti eseguano la stessa proposta, acquisisci o blocca atomicamente la transizione da approved a executing: un solo worker può acquisirla, se la proposta è ancora approvata e valida. In questa protezione locale, verifica anche l’idempotenza e registra l’identificatore univoco dell’operazione prima di proseguire. Questo evita duplicati all’interno del sistema, ma una transazione sul database non garantisce, da sola, che un’API esterna applichi un effetto una sola volta.
Se l’azione avviene in un altro servizio, usa una chiave di idempotenza che il servizio accetti ed elabori in modo idempotente, se disponibile. Registra l’identificatore di correlazione, il tentativo e le risposte. Se la risposta va persa o il risultato è sconosciuto, non ripetere l’operazione alla cieca: consulta lo stato remoto usando quell’identificatore oppure riconcilia il risultato con dati affidabili. Se non è possibile confermare se l’effetto si è verificato, interrompi i nuovi tentativi automatici e assegna il caso a una persona addetta alle operazioni. Un errore noto prima dell’invio della richiesta può consentire un nuovo tentativo, a condizione di verificare nuovamente lo stato e l’autorizzazione.
Se un worker si arresta e lascia una proposta in executing, non contrassegnarla automaticamente come eseguita e non inviarla di nuovo senza prima aver effettuato una diagnosi. Un processo di recupero deve stabilire se l’effetto si è verificato, usando il registro locale e, quando opportuno, interrogando il servizio remoto. Se conferma che non si è verificato, può riportare la proposta a uno stato eseguibile solo dopo aver convalidato nuovamente la validità, i dati e l’autorizzazione; se il risultato rimane sconosciuto, deve mantenerla bloccata e inoltrare il caso a un livello superiore.
Progettare una coda operativa e un’alternativa manuale
La coda deve consentire di trovare le richieste in attesa in base all’anzianità, all’impatto, al responsabile e alla data di scadenza, oltre a mostrare il contesto su cui si basa la decisione. Spiega perché un caso è bloccato e quale azione è prevista: attendere, richiedere modifiche, annullare o inoltrare il caso. L’interfaccia deve anche chiarire che cosa accadrà dopo l’approvazione, non limitarsi a offrire pulsanti per decidere.
Definisci un’alternativa in caso di guasto di una dipendenza, come il servizio di notifica o un’integrazione necessaria per eseguire l’azione. È possibile mantenere la proposta in attesa e fornire una procedura controllata che consenta a una persona autorizzata di esaminare il caso nel sistema disponibile. La procedura manuale deve rispettare gli stessi controlli, registrare l’autore dell’azione e il motivo, evitare esecuzioni parallele e riconciliare il risultato al ripristino dell’integrazione.
Non trasformare un guasto tecnico in un’approvazione implicita. Se non è possibile verificare l’identità, i permessi o le informazioni necessarie, il sistema deve fallire in modo sicuro: sospendere, informare e inoltrare il caso. Definisci chi può sbloccare il processo, come documentare l’intervento e quali attività devono essere riesaminate al ripristino del servizio.
Testare il flusso e monitorarne il funzionamento
Testa le regole di dominio e i percorsi completi: approvazione, rifiuto, richiesta di modifiche, scadenza, annullamento e nuovi tentativi. Aggiungi test dei permessi per verificare che chi non è autorizzato non possa modificare lo stato e test di concorrenza per assicurarti che due decisioni simultanee non producano due esecuzioni.
Includi casi in cui i dati cambiano durante l’attesa o subito prima dell’esecuzione, l’esecuzione remota fallisce dopo aver accettato la richiesta e una risposta va persa anche se l’effetto si è verificato. Verifica che l’acquisizione atomica consenta a un solo worker di eseguire la proposta, che i nuovi tentativi rifiutino le autorizzazioni scadute e che ogni intervento manuale lasci un registro sufficiente. In produzione, monitora il volume e l’anzianità delle richieste in attesa, le scadenze, gli errori di esecuzione e i casi che richiedono una riconciliazione.
Un flusso progettato correttamente mantiene la supervisione umana dove offre un controllo reale, senza affidare la sicurezza alla memoria dei team. Stati espliciti, permessi separati, dati esaminati ancora validi, esecuzione idempotente e un percorso chiaro in caso di guasti trasformano un’approvazione informale in un processo verificabile.
