Automazioni di marketing: quando riprovare senza duplicare le azioni

Si può riprovare senza un secondo effetto con identità dell’operazione, stato salvato e protezioni adeguate. Un timeout indica che chi invia ha smesso di aspettare, non che il destinatario abbia interrotto il lavoro.

Concordate con chi realizza il flusso quali prove autorizzano a riprovare, proseguire o richiedere una verifica. Un tentativo tecnico aggiuntivo può appartenere alla stessa operazione.

Prima di ripartire, ricostruire cosa è successo

Consideriamo un esempio dichiaratamente fittizio, mai eseguito. Una richiesta di campagna deve creare una sola attività di ricontatto nel CRM. Il CRM la salva, ma la risposta si perde. Ripetere tutto il flusso rischia di crearne un'altra. La scelta sensata è cercare l'attività esistente attraverso un riferimento univoco, registrarne l'identificativo nel CRM e proseguire dalla fase ancora in sospeso. Se il risultato non è verificabile, il caso resta fermo.

Distinguete tre stati: errore accertato prima dell'azione, che permette di riprovare secondo le regole; azione conclusa, di cui riutilizzare il risultato; esito incerto, da verificare presso il destinatario.

Per esempio, Shopify Flow attende fino a dieci secondi per la risposta dei propri endpoint di azioni personalizzate; poi chiude la connessione e invia di nuovo in seguito. L'action_run_id nel contenuto della richiesta può aiutare il destinatario a riconoscere la ripetizione, ma non elimina da solo le azioni duplicate. Il limite dei dieci secondi riguarda questi endpoint, non qualsiasi webhook, CRM o servizio di IA.

Concordare quale operazione deve restare la stessa

Un webhook è una notifica automatica di un evento. La stessa notifica può arrivare più volte. Shopify consiglia una gestione idempotente o il tracciamento dell'identificativo del webhook. Inoltre, sottoscrizioni diverse possono produrre identificativi di consegna distinti per la stessa azione del commerciante, pur condividendo l'identificativo dell'evento. Identità della consegna e identità dell'operazione non coincidono necessariamente. Vanno preservate le azioni separate davvero volute.

Assegnate perciò all'operazione un identificativo stabile, senza dati personali incorporati. Ogni tentativo tecnico avrà un proprio identificativo, mentre quello dell'operazione resta invariato. Un'azione nuova richiede una nuova identità e approvazione, dopo aver chiarito l'eventuale operazione precedente ancora incerta.

Il registro persistente deve conservare identificativo dell'operazione, evento e fonte, azione prevista, dati approvati e relativa versione, stato, numero di tentativi, riferimento del destinatario e orari. Deve indicare anche responsabile e decisione successiva. Per il registro dimostrativo non servono dettagli sensibili dei clienti.

Chiedere come viene impedito il secondo effetto

Idempotenza significa che ripetere la stessa operazione prevista non aggiunge un altro effetto, entro le condizioni documentate dal sistema. Verificate richieste supportate, durata, parametri ed errori. Anche un esito incerto può essere chiarito tramite una ripetizione protetta, prevista dalla documentazione, con la stessa chiave e gli stessi parametri entro il periodo valido.

Stripe esemplifica queste condizioni, senza proporre qui automazioni di pagamento. Per le richieste POST supportate, la stessa chiave di idempotenza restituisce il primo stato e contenuto di risposta salvati, compresi gli errori. Parametri diversi con la stessa chiave generano un errore. Le chiavi possono essere eliminate dopo almeno 24 ore; riutilizzarle dopo l'eliminazione produce una nuova richiesta. Il risultato viene salvato solo quando inizia l'esecuzione dell'endpoint: errori di validazione e conflitti tra richieste contemporanee seguono regole diverse. Questa durata non è uno standard universale.

Un controllo locale del tipo «già fatto?» è insufficiente: due processi contemporanei possono superarlo entrambi. Oppure l'azione esterna riesce prima che il successo sia registrato localmente. Chiedete una prenotazione atomica, cioè un'assegnazione indivisibile dell'operazione, per esempio tramite un vincolo di unicità nel database. Serve anche la protezione del destinatario oppure una verifica affidabile del risultato. Scrivere un identificativo o registrare il successo dopo l'azione non offre, da solo, una garanzia.

Quando il destinatario non sa confermare l'esito né impedire una duplicazione, il flusso deve fermarsi e passare il caso a una persona designata. Non va autorizzato un nuovo invio automatico alla cieca.

Riprendere dal punto giusto, con il contenuto già approvato

Creazione nel CRM e invio dell'email richiedono conferme distinte; l'accettazione dell'email non prova la consegna. Si ripete solo il passaggio irrisolto quando consentito, conservando i dati approvati. Rigenerare un testo può cambiarlo: il contenuto modificato richiede revisione.

Una pausa per l'approvazione umana non basta a evitare ripetizioni. In LangGraph, riprendere dopo una pausa con interrupt() riesegue dall'inizio il nodo, ossia una fase del programma; le modifiche esterne compiute prima della pausa possono ripetersi. La documentazione suggerisce operazioni idempotenti oppure di separare o spostare questi effetti. Separare le fasi è utile, ma non garantisce protezione da ogni errore successivo. L'IA può preparare bozze o classificare un errore; le azioni con conseguenze sono governate da regole deterministiche e da un responsabile umano. Un prompt migliore non sostituisce queste regole.

I casi da verificare prima dell'avvio

Questi sono criteri proposti con casi di prova illustrativi, non risultati di test eseguiti né una certificazione:

1. Esecuzione ordinaria riuscita: azione prevista confermata e riferimento esterno conservato.
2. Stesso evento ricevuto due volte: nei casi protetti, una sola azione prevista e riuso delle prove disponibili.
3. Timeout dopo il successo del destinatario: verifica e riuso del risultato; esito ancora incerto sospeso per revisione.
4. Due tentativi simultanei: prenotazione e protezione del destinatario impediscono il secondo effetto nel perimetro concordato.
5. Ripresa dopo approvazione: conservazione dei dati approvati e dei passaggi già confermati.
6. Ripetizione tardiva oltre il periodo di conservazione: controllo delle prove precedenti, senza nuova azione automatica se manca certezza.

Misurate separatamente eventi, tentativi, effetti esterni confermati, casi irrisolti e tempo impiegato dagli operatori per il recupero. Stabilite un limite ai tentativi e intervalli di attesa secondo le regole documentate di ciascun destinatario, evitando ripetizioni infinite.

Il servizio di automazione MindVerve definisce eventi di avvio, dati in ingresso, risultati, responsabili, gestione dei dati mancanti e degli errori, casi di prova e istruzioni operative. AI Workflow Launch configura un solo flusso concordato: scelta degli strumenti, prove rappresentative e di errore, brief e prompt riutilizzabili, documentazione, formazione e passaggio di consegne. Licenze, uso delle API e integrazioni aggiuntive sono esclusi; la manutenzione continuativa è separata.