Shopify Flow: automazioni su Basic, Grow e Advanced

Postazione e-commerce con un flusso di automazione visualizzato su laptop, simbolo di Shopify Flow

Shopify Flow serve ad automatizzare processi ripetitivi e deterministici senza trasformare ogni esigenza operativa in un’app custom. La logica è semplice: un evento avvia il workflow, una o più condizioni decidono il percorso e le azioni eseguono ciò che hai definito. La parte importante, però, non è “quante automazioni puoi creare”: è capire quali processi sono abbastanza chiari, osservabili e reversibili da meritare un workflow.

Al 18 settembre 2026, Shopify Flow è un’app gratuita disponibile sui piani Basic, Grow e Advanced. La maggior parte delle funzioni è condivisa, ma non tutto è uguale tra i piani: per esempio, l’azione Send HTTP Request è disponibile su Grow e Advanced, non su Basic. Anche i limiti operativi dipendono dai limiti API associati al piano.

Cos’è Shopify Flow, in pratica

Un workflow Flow è composto da tre elementi: trigger, condizioni e azioni. Il trigger è l’evento che avvia il flusso; le condizioni valutano i dati disponibili; le azioni modificano dati, inviano notifiche o attivano altri passaggi. È un modello adatto soprattutto quando la regola può essere descritta in modo netto: “se succede X e sono vere Y e Z, allora fai A”.

Questo lo rende molto diverso da un sistema AI che interpreta un contesto aperto. Flow è più utile quando vuoi ottenere un comportamento prevedibile. Se un ordine soddisfa certe condizioni, puoi taggarlo; se una situazione richiede attenzione, puoi inviare una notifica; se un controllo periodico trova determinati record, puoi elaborarli con un ciclo.

Per il quadro più ampio su AI e automazione, ho separato il tema in questa guida su AI e automazione Shopify. Flow non sostituisce quel livello: copre soprattutto l’automazione deterministica.

Basic, Grow e Advanced: cosa cambia davvero

La prima distinzione utile è tra automazioni interne a Shopify e integrazioni verso sistemi esterni.

Su Basic puoi usare Shopify Flow e costruire workflow con trigger, condizioni e molte azioni native. Quello che non hai è l’azione Send HTTP Request. Su Grow e Advanced, invece, puoi usare anche questa azione per inviare richieste a un endpoint esterno. Shopify indica inoltre che Flow applica limiti di utilizzo differenti in funzione dei limiti API del piano.

Questo non significa che Grow o Advanced siano “necessari per automatizzare”. Significa che, quando il workflow deve uscire da Shopify e dialogare direttamente con un servizio via HTTP, il piano diventa un vincolo tecnico da verificare prima di progettare il flusso.

Prima regola: automatizzare un processo, non un’idea

Un workflow affidabile parte da un processo già definito. Prima di aprire Flow, conviene scrivere la regola in una riga: quando succede cosa, su quali dati, con quali eccezioni e con quale risultato finale?

Se non riesci a descriverla con chiarezza, il problema non è ancora “da Flow”. Automatizzare un processo ambiguo sposta semplicemente l’ambiguità dentro un sistema che poi può lavorare in modo coerente… ma coerentemente sbagliato.

Per questo, nella progettazione parto sempre da quattro domande:

qual è l’evento che deve avviare il processo;
quali condizioni devono essere vere prima di agire;
quale azione è realmente necessaria;
come verifico dopo l’esecuzione che il risultato sia corretto.

Cinque casi in cui Flow ha senso

1. Tag operativi su ordini e clienti

I tag sono utili quando servono a classificare casi che poi devono essere filtrati, controllati o gestiti da altri processi. Un esempio semplice è aggiungere un tag a un ordine quando rispetta una combinazione precisa di condizioni, oppure segmentare un cliente sulla base di informazioni già disponibili nel workflow.

La regola qui è evitare tag “decorativi”. Se il tag non alimenta una vista, una procedura, un’altra automazione o un controllo, sta solo creando rumore.

2. Controlli periodici su ordini

Con un trigger programmato e le azioni Get data puoi costruire controlli periodici. Shopify documenta, per esempio, workflow che recuperano ordini non evasi da un certo numero di giorni, applicano un tag o inviano un riepilogo. Le azioni Get data possono restituire fino a 100 risorse alla volta, quindi il volume va considerato nel design.

3. Notifiche interne quando serve davvero intervenire

Flow è efficace per trasformare una condizione operativa in una segnalazione. Il valore non è ricevere più email: è ricevere una notifica soltanto quando un evento richiede una decisione umana. Se ogni ordine genera un alert, l’automazione ha solo spostato il rumore da Shopify alla casella di posta.

4. Azioni Admin API non presenti come blocco standard

L’azione Send Admin API request permette di usare molte mutation della GraphQL Admin API anche quando l’operazione non è disponibile come azione Flow dedicata. È un’estensione potente, ma ha limiti precisi: lavora con mutation, non con query, e non tutte le mutation sono supportate.

Qui serve più disciplina rispetto a un’azione standard: una modifica API può avere effetti più ampi, quindi input, identificativi e condizioni devono essere controllati con attenzione.

5. Integrazioni HTTP verso servizi esterni

Su Grow e Advanced, Send HTTP Request consente di inviare una richiesta a un URL esterno. Shopify documenta un’attesa massima di 30 secondi per la risposta; in caso di mancata risposta, la connessione viene chiusa e la richiesta può essere ritentata successivamente.

Se l’obiettivo è modificare dati Shopify tramite GraphQL Admin API, Shopify suggerisce invece di usare Send Admin API request. È una distinzione utile: HTTP serve a collegare Flow a un servizio esterno; l’azione Admin API è pensata per operazioni Shopify.

Testare prima di attivare non è opzionale

Flow permette di testare un workflow prima dell’attivazione. I test possono usare eventi registrati, dati reali del negozio oppure eventi simulati; Shopify consente anche di generare eventi di test con Sidekick.

Il punto più importante è che il test non esegue azioni che modificano i dati live. Quando il flusso arriva alla prima azione che produrrebbe una modifica, il test si ferma. Per le azioni che chiamano servizi esterni, il test può mostrare la configurazione ma non simulare la risposta reale del servizio.

Quindi il test serve a validare logica, variabili, condizioni e percorso del workflow. Non sostituisce una verifica controllata del comportamento reale dopo l’attivazione.

Dopo l’attivazione: guardare i run, non fidarsi del diagramma

Un workflow corretto nel canvas può comunque incontrare dati inattesi, errori temporanei o limiti di esecuzione. Shopify registra i workflow run, cioè i log delle esecuzioni, e li conserva per 14 giorni. Da lì puoi verificare cosa è successo nei singoli passaggi.

Quando una run fallisce e hai corretto la causa, Flow consente anche il retry manuale. Va ricordato che un retry riutilizza i dati del trigger originale ma può recuperare dati aggiornati dalle azioni Get data e rieseguire condizioni e azioni sullo stato corrente. Non è quindi una semplice “ripetizione fotografica” del passato.

Esiste inoltre il trigger Workflow error occurred, utile per costruire una notifica dedicata agli errori. Per i processi che incidono davvero sull’operatività, un canale di errore è più importante dell’ennesimo workflow “intelligente”.

Rate limit, timeout e idempotenza: i problemi arrivano qui

Shopify segnala che Flow può limitare intenzionalmente l’esecuzione quando uno o più workflow consumano troppe risorse. Il risultato può essere un ritardo o, in alcuni casi, un timeout.

Per questo conviene progettare pensando anche alla ripetizione. Se una stessa azione venisse eseguita due volte, creerebbe un doppione, un secondo invio o uno stato incoerente? Se la risposta è sì, serve un controllo di idempotenza: un tag, un metafield, uno stato verificabile o una condizione che impedisca di applicare due volte la stessa operazione.

Questo aspetto diventa ancora più importante quando Flow chiama sistemi esterni. Un “retry” non dovrebbe trasformarsi automaticamente in una doppia operazione.

Quando Flow non basta

Flow funziona molto bene quando il processo è event-driven, deterministico e relativamente locale. Inizia a diventare il livello sbagliato quando servono stato applicativo complesso, autenticazioni esterne articolate, code, elaborazioni lunghe, database dedicati, logiche multi-store o interfacce merchant specifiche.

In quei casi un’app Shopify embedded o un backend dedicato può essere più pulito e controllabile. Allo stesso modo, se la logica deve intervenire direttamente nel comportamento di checkout o in funzioni commerce supportate dalla piattaforma, il tema può spostarsi verso Shopify Functions e sviluppo app custom, non verso un workflow Flow sempre più grande.

La scelta corretta non è “Flow oppure app” in assoluto. È usare Flow finché il problema resta un workflow; passare a codice quando stai cercando di usare un workflow come se fosse un’applicazione.

Flow non serve a eliminare tutte le app

Una buona automazione può sostituire piccole utility ridondanti, ma non ha senso valutare le app solo per quantità. Se un’app fornisce una funzione stabile, mantiene integrazioni, espone una UX dedicata o gestisce complessità che Flow non dovrebbe assorbire, rimuoverla può peggiorare il sistema.

Se stai facendo pulizia dello stack, la logica corretta è quella che descrivo nella guida su costi, performance e sostituzione delle app Shopify: capire prima quale problema risolve ogni componente, poi decidere se mantenerlo, sostituirlo o eliminarlo.

Il criterio che uso per decidere

Per me Flow è una buona scelta quando posso descrivere il processo con una regola verificabile, il risultato è osservabile e un errore può essere individuato rapidamente. Se invece il workflow accumula eccezioni, chiamate esterne, dipendenze e stato, non lo considero più “semplice solo perché è visuale”.

Il vantaggio di Flow non è evitare il codice a ogni costo. È tenere semplici i processi che sono davvero semplici, usando uno strumento nativo e leggibile. Quando il problema supera quella soglia, conviene cambiare architettura prima che l’automazione diventi il nuovo punto fragile dello store.