Perché Shopify Flow non può confrontare le date (e cosa funziona davvero)

Se hai passato un pomeriggio a cercare di far confrontare a Shopify Flow una data di metafield con la data di oggi, non stai sbagliando. Flow genuinamente non può farlo in modo pulito, e le ragioni per cui vale la pena capirle prima di sprecare un'altra ora in workaround. Questa è la risposta lunga, più il percorso breve per aggirarlo.

Il problema, in parole semplici

Vuoi qualcosa che suona semplice. Verifica se il metafield expiry_date di un prodotto è passato, e in tal caso, sposta il prodotto in bozza. Oppure verifica se oggi è la launch_date di un prodotto, e in tal caso, pubblicalo. Oppure attiva un tag due settimane prima dell'inizio di una promozione. Sono il tipo di regole di prodotto basate su data di cui ogni negozio Shopify sufficientemente reale ha alla fine bisogno, e il tipo che Shopify Flow sembra dover gestire.

Tranne che Flow non funziona così. Ci sono tre muri separati contro cui sbatterai. La maggior parte dei merchant li incontra tutti e tre prima di arrendersi.

Muro 1: I campi condizione di Flow non accettano Liquid

Quando costruisci una condizione in Flow, confronti un valore con una stringa fissa. Puoi dire "tag prodotto uguale a on-sale", oppure "stato prodotto uguale ad Attivo". Quello che non puoi dire è "data di metafield del prodotto è minore di oggi", perché "oggi" non è un valore fisso che puoi digitare. Cambia ogni giorno.

Il workaround intuitivo è Liquid. Già usi Liquid nel tuo tema, hai visto Liquid nelle azioni e-mail di Flow, quindi provi la cosa ovvia:

{{ "now" | date: "%Y-%m-%d" }}

E non funziona. Liquid è supportato nei campi azione di Flow (il corpo di un'e-mail, il valore passato a una richiesta HTTP), ma non nei campi condizione. Il sistema di condizioni tratta il tuo Liquid come una stringa letterale. La tua bellissima espressione confronta i caratteri {{ "now" | date: "%Y-%m-%d" }} con una data ISO reale, che non corrisponderà mai.

Questo coglie quasi tutti di sorpresa, perché l'asimmetria non è documentata in modo prominente. La superficie del prodotto implica che Liquid sia un cittadino di prima classe in tutto Flow. Non lo è.

Muro 2: Non puoi interrogare i prodotti per data di metafield tramite l'API

Magari rinunci a Liquid e provi l'altro approccio ovvio: un Flow pianificato che gira quotidianamente e recupera i prodotti con una data scaduta. È a questo che servono gli attivatori pianificati, no?

Tranne che l'API Shopify Admin non supporta il filtraggio dei prodotti per valori di data di metafield. La query dei prodotti supporta il filtraggio per stato, titolo, fornitore, tipo di prodotto, tag, tempo di creazione/aggiornamento e una manciata di altri campi di primo livello. Il confronto di date di metafield non è nell'elenco. Non c'è un filtro metafield:custom.expiry_date<today.

La posizione ufficiale di Shopify è che i metafield sono dati di estensione flessibili, non indicizzati per query economiche. È una scelta architetturale ragionevole. È anche il muro che trasforma un progetto da una serata in uno molto più grande.

Qualsiasi Flow pianificato che voglia agire su "prodotti con una data di scadenza passata" deve recuperare ogni prodotto, fare il parsing del metafield e filtrare nel codice. Il che ci porta al muro tre.

Muro 3: Il workaround Run Code è fragile

Flow ha un'azione "Run Code" che ti permette di scrivere JavaScript dentro un'automazione. Con sufficiente sforzo puoi costruire un flow che fa questo:

1. Si attiva su una pianificazione quotidiana.
2. Run Code recupera i prodotti in pagine dall'API Admin GraphQL.
3. Per ogni prodotto, legge il metafield custom.expiry_date.
4. Fa il parsing della stringa ISO in una data, la confronta con l'ora corrente.
5. Per le corrispondenze, attiva un'azione di cambio stato.

Funziona. È anche molto lontano dalla promessa "no-code" di Flow.

Stai mantenendo JavaScript dentro un'automazione Shopify. Gestisci la paginazione se il tuo catalogo è più grande di una singola pagina. Gestisci i metafield mancanti. Gestisci i prodotti con date malformate perché qualcuno ha modificato a mano un CSV. Gestisci i rate limit dell'API quando il tuo catalogo cresce. Se Shopify deprecca un campo nel prossimo aggiornamento di versione API, il tuo flow potrebbe fallire silenziosamente e te ne accorgerai solo la prossima volta che un prodotto non viene archiviato in tempo.

Per uno sviluppatore a suo agio con quella manutenzione, va bene. Per un merchant che voleva solo che un prodotto si mettesse da solo in bozza alla scadenza, è genuinamente troppo. E ogni conversazione che ho con merchant che l'hanno provato finisce allo stesso modo: l'hanno costruito, ha funzionato per un trimestre, poi qualcosa si è rotto silenziosamente e non se ne sono accorti per tre settimane.

Cosa funziona davvero: uno strumento costruito per il lavoro

DateCue esiste perché continuavo a sbattere contro questo esatto muro e mi sono stancato di consigliare Run Code a merchant che non se lo meritavano. Il modello è semplice: metti una data in un metafield di prodotto, DateCue la monitora, e quando la data è dovuta attiva l'azione che hai configurato. Cambio di stato, cambio di tag o e-mail al personale.

Niente Liquid. Niente JavaScript. Nessuna logica di paginazione API. Tre campi e un pulsante di salvataggio.

Ecco il flusso di lavoro di scadenza che avrebbe richiesto ore per essere costruito in Flow:

DateCue raccoglie ogni prodotto con un metafield custom.expiry_date, monitora la data, e lo sposta in bozza entro un minuto dal passaggio della data. Il filtro di stato Attivo è la protezione che assicura che DateCue tocchi solo i prodotti che sono attualmente online, in modo da non ritoccare i prodotti che hai già messo manualmente in bozza per altri motivi.

Quanto velocemente è "entro un minuto", davvero?

Ci sono due orologi in funzione. L'esecutore di azioni controlla i flussi di lavoro dovuti ogni minuto. La sincronizzazione di prodotto che recupera i valori freschi dei metafield da Shopify gira ogni cinque minuti. Quindi se imposti un metafield a una data nel passato proprio adesso, DateCue prende il nuovo valore alla prossima sincronizzazione (fino a cinque minuti) e attiva l'azione al prossimo tick dell'esecutore (fino a un minuto dopo).

Se hai bisogno che un valore nuovo di zecca venga preso più velocemente — diciamo, stai aggiornando una data di lancio sessanta secondi prima che si attivi — premi Sincronizza ora nel pannello di controllo. Il metafield viene caricato immediatamente e l'azione si attiva al prossimo tick di minuto.

Per qualsiasi data impostata in anticipo (che è quasi tutto l'uso del mondo reale), l'azione si attiva entro lo stesso minuto in cui la data passa. Imposta un lancio per le 10:00, il prodotto è online entro le 10:01.

Lo stesso modello gestisce più che la sola scadenza

La cosa che Flow non può fare — confrontare una data di metafield con oggi — è esattamente la primitiva che sblocca la maggior parte delle regole di prodotto basate su data. Una volta che ce l'hai, i casi d'uso si accumulano:

• Pubblica automaticamente un prodotto alla sua data di lancio leggendo un metafield launch_date.
• Pubblica e nascondi i prodotti stagionali all'inizio e alla fine di una finestra.
• Tagga i prodotti come "in scadenza" due settimane prima che scadano per alimentare una collezione outlet.
• Invia un'e-mail al tuo buyer 30 giorni prima della scadenza dello stock in modo che abbia tempo di riordinare.
• Termina automaticamente una promozione rimuovendo il tag on-sale alla data di fine.

Ognuno è un singolo flusso di lavoro in DateCue con tempistica e azione diverse. Le cose che sono genuinamente difficili in Flow — calcolo di date, query pianificate, confronti di metafield — sono esattamente quelle che DateCue gestisce nativamente.

Ti serve ancora Flow?

Quasi sicuramente sì, e va bene così. Flow è eccellente nelle cose per cui è stato progettato. Taggare ordini ad alto valore, screening antifrode, customer journey post-acquisto, avvisi di scorta bassa al tuo magazzino, qualsiasi cosa attivata da un evento ordine o evento cliente — Flow gestisce tutto questo bene, e DateCue non cerca di farlo.

La divisione è pulita. Flow gestisce gli eventi che si attivano dal lato ordine o cliente. DateCue gestisce gli eventi che si attivano da una data su un prodotto. Coesistono senza alcuna integrazione, perché non competono per gli stessi attivatori.

Migrare da un flusso di lavoro Run Code

Se hai già un flusso di lavoro Run Code che gestisce l'automazione di prodotto basata su data, la migrazione è breve. Il pattern seguente tende a funzionare:

1. Installa DateCue dallo Shopify App Store. Il piano gratuito è sufficiente per testare.
2. Ricrea l'azione in un flusso di lavoro DateCue: scegli il metafield, la tempistica e l'azione.
3. Disabilita il flusso di lavoro Run Code in Flow (non eliminarlo ancora).
4. Osserva il registro di esecuzione di DateCue per una settimana. Ogni azione attivata appare con il prodotto, la data che l'ha attivata e il risultato.
5. Una volta confermato che DateCue sta facendo il lavoro, elimina il vecchio flusso di lavoro Run Code.

La maggior parte delle migrazioni richiede meno di un'ora. La parte lenta è la verifica, non la configurazione.

Matt Burrell

Fondatore di Ripen Studio. Ho costruito DateCue perché continuavo a sbattere contro questo esatto muro e mi sono stancato di consigliare Run Code a merchant che non se lo meritavano. Maggiori informazioni su Matt.