Pourquoi Shopify Flow ne peut pas comparer les dates (et ce qui fonctionne vraiment)

Si vous avez passé un après-midi à essayer de faire en sorte que Shopify Flow compare une date de champs méta à la date d'aujourd'hui, vous ne vous y prenez pas mal. Flow ne peut vraiment pas le faire proprement, et les raisons valent la peine d'être comprises avant de gaspiller une autre heure sur des contournements. Voici la réponse longue, plus le chemin court pour la contourner.

Le problème, énoncé clairement

Vous voulez quelque chose qui semble simple. Vérifier si le champs méta expiry_date d'un produit est passé, et si oui, passer le produit en brouillon. Ou vérifier si aujourd'hui est la launch_date d'un produit, et si oui, le publier. Ou déclencher une balise deux semaines avant le début d'une promotion. Ce sont les types de règles produit basées sur les dates dont toute boutique Shopify suffisamment réelle finit par avoir besoin, et le type que Shopify Flow semble pouvoir gérer.

Sauf que Flow ne fonctionne pas comme ça. Il y a trois murs distincts que vous rencontrerez. La plupart des marchands rencontrent les trois avant d'abandonner.

Mur 1 : Les champs de condition de Flow n'acceptent pas Liquid

Lorsque vous construisez une condition Flow, vous comparez une valeur à une chaîne fixe. Vous pouvez dire « balise de produit égale on-sale », ou « statut du produit égal Actif ». Ce que vous ne pouvez pas dire est « la date du champs méta du produit est inférieure à aujourd'hui », parce que « aujourd'hui » n'est pas une valeur fixe que vous pouvez taper. Elle change chaque jour.

Le contournement intuitif est Liquid. Vous utilisez déjà Liquid dans votre thème, vous avez vu Liquid dans les actions e-mail de Flow, alors vous essayez la chose évidente :

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

Et cela ne fonctionne pas. Liquid est pris en charge dans les champs d'action de Flow (le corps d'un e-mail, la valeur passée à une requête HTTP), mais pas dans les champs de condition. Le système de condition traite votre Liquid comme une chaîne littérale. Votre belle expression compare les caractères {{ "now" | date: "%Y-%m-%d" }} à une date ISO réelle, ce qui ne correspondra jamais.

Cela prend presque tout le monde par surprise, parce que l'asymétrie n'est pas documentée de façon visible. La surface du produit implique que Liquid est un citoyen de première classe dans tout Flow. Ce n'est pas le cas.

Mur 2 : Vous ne pouvez pas interroger les produits par date de champs méta via l'API

Vous abandonnez peut-être Liquid et essayez l'autre approche évidente : un Flow planifié qui s'exécute quotidiennement et récupère les produits avec une date expirée. C'est à cela que servent les déclencheurs planifiés, non ?

Sauf que l'API Admin Shopify ne prend pas en charge le filtrage des produits par valeurs de date de champs méta. La requête de produit prend en charge le filtrage par statut, titre, fournisseur, type de produit, balise, heure de création/mise à jour, et une poignée d'autres champs de premier niveau. La comparaison de date de champs méta n'est pas dans la liste. Il n'y a pas de filtre metafield:custom.expiry_date<today.

La position officielle de Shopify est que les champs méta sont des données d'extension flexibles, pas indexées pour des requêtes peu coûteuses. C'est un choix architectural raisonnable. C'est aussi le mur qui transforme un projet d'une soirée en un beaucoup plus gros.

Tout Flow planifié qui veut agir sur « les produits avec une date d'expiration passée » doit récupérer chaque produit, analyser le champs méta et filtrer dans le code. Ce qui nous amène au mur trois.

Mur 3 : La solution de contournement Run Code est fragile

Flow a une action « Run Code » qui vous permet d'écrire du JavaScript à l'intérieur d'une automatisation. Avec assez d'efforts, vous pouvez construire un flux qui fait ceci :

1. Se déclenche sur une planification quotidienne.
2. Run Code récupère les produits par pages depuis l'API Admin GraphQL.
3. Pour chaque produit, lit le champs méta custom.expiry_date.
4. Analyse la chaîne ISO en date, la compare à l'heure actuelle.
5. Pour les correspondances, déclenche une action de changement de statut.

Ça marche. C'est aussi très loin de la promesse « sans code » de Flow.

Vous maintenez du JavaScript à l'intérieur d'une automatisation Shopify. Vous gérez la pagination si votre catalogue est plus grand qu'une seule page. Vous gérez les champs méta manquants. Vous gérez les produits avec des dates mal formées parce que quelqu'un a édité manuellement un CSV. Vous gérez les limites de débit d'API quand votre catalogue grandit. Si Shopify déprécie un champ lors du prochain changement de version d'API, votre flux pourrait échouer silencieusement et vous ne le remarqueriez que la prochaine fois qu'un produit ne s'archive pas à temps.

Pour un développeur à l'aise avec cette maintenance, c'est bien. Pour un marchand qui voulait juste qu'un produit se mette en brouillon quand il expire, c'est vraiment trop. Et chaque conversation que j'ai avec des marchands qui ont essayé se termine de la même façon : ils l'ont construit, ça a marché pendant un trimestre, puis quelque chose s'est cassé silencieusement et ils ne s'en sont pas aperçus pendant trois semaines.

Ce qui fonctionne vraiment : un outil conçu pour ce travail

DateCue existe parce que je continuais à rencontrer ce mur exact et que j'en avais assez de recommander Run Code à des marchands qui ne le méritaient pas. Le modèle est simple : vous mettez une date dans un champs méta de produit, DateCue la surveille, et lorsque la date est due, il déclenche l'action que vous avez configurée. Changement de statut, changement de balise ou e-mail au personnel.

Pas de Liquid. Pas de JavaScript. Pas de logique de pagination d'API. Trois champs et un bouton enregistrer.

Voici le flux de travail d'expiration qui aurait pris des heures à construire dans Flow :

DateCue prend en compte chaque produit avec un champs méta custom.expiry_date, suit la date, et passe le produit en brouillon dans la minute qui suit le passage de la date. Le filtre de statut Actif est le garde-fou qui s'assure que DateCue ne touche que les produits actuellement en ligne, donc il ne re-touchera pas les produits que vous avez déjà mis manuellement en brouillon pour d'autres raisons.

À quelle vitesse, « dans la minute », vraiment ?

Deux horloges tournent. L'exécuteur d'actions vérifie les flux de travail dus toutes les minutes. La synchronisation de produits qui récupère les valeurs fraîches de champs méta depuis Shopify s'exécute toutes les cinq minutes. Donc si vous définissez un champs méta à une date dans le passé maintenant, DateCue prend en compte la nouvelle valeur à la prochaine synchronisation (jusqu'à cinq minutes) et déclenche l'action à la prochaine tick d'exécuteur (jusqu'à une minute après).

Si vous avez besoin qu'une toute nouvelle valeur soit prise en compte plus rapidement — disons, vous mettez à jour une date de lancement soixante secondes avant qu'elle ne se déclenche — cliquez sur Synchroniser maintenant dans le tableau de bord. Le champs méta est chargé immédiatement et l'action se déclenche à la prochaine tick de minute.

Pour toute date définie à l'avance (ce qui couvre presque tous les usages réels), l'action se déclenche dans la même minute où la date passe. Définissez un lancement pour 10h00, le produit est en ligne à 10h01.

Le même modèle gère plus que la simple expiration

La chose que Flow ne peut pas faire — comparer une date de champs méta à aujourd'hui — est exactement la primitive qui débloque la plupart des règles produit basées sur les dates. Une fois que vous l'avez, les cas d'usage s'empilent :

• Publier automatiquement un produit à sa date de lancement en lisant un champs méta launch_date.
• Publier et masquer les produits saisonniers au début et à la fin d'une fenêtre.
• Baliser les produits comme « expires soon » deux semaines avant qu'ils n'expirent pour alimenter une collection de déstockage.
• Envoyer un e-mail à votre acheteur 30 jours avant l'expiration du stock pour qu'il ait le temps de commander à nouveau.
• Terminer une promotion automatiquement en retirant la balise on-sale à la date de fin.

Chacun est un flux de travail unique dans DateCue avec un déclenchement et une action différents. Les choses qui sont véritablement difficiles dans Flow — calcul de date, requêtes planifiées, comparaisons de champs méta — sont exactement ce que DateCue gère nativement.

Avez-vous encore besoin de Flow ?

Presque certainement oui, et c'est bien. Flow est excellent pour les choses pour lesquelles il a été conçu. Baliser les commandes à haute valeur, le filtrage anti-fraude, les parcours clients post-achat, les alertes de stock bas vers votre entrepôt, tout ce qui est déclenché par un événement de commande ou un événement client — Flow gère tout cela bien, et DateCue n'essaie pas.

La séparation est nette. Flow gère les événements qui se déclenchent depuis le côté commande ou client. DateCue gère les événements qui se déclenchent à partir d'une date sur un produit. Ils coexistent sans aucune intégration, parce qu'ils ne se disputent pas les mêmes déclencheurs.

Migration depuis un flux de travail Run Code

Si vous avez déjà un flux de travail Run Code qui gère l'automatisation de produits basée sur les dates, la migration est courte. Le schéma ci-dessous fonctionne généralement :

1. Installez DateCue depuis le Shopify App Store. Le forfait gratuit suffit pour tester.
2. Recréez l'action dans un flux de travail DateCue : choisissez le champs méta, le déclenchement et l'action.
3. Désactivez le flux de travail Run Code dans Flow (ne le supprimez pas encore).
4. Surveillez le journal d'exécution de DateCue pendant une semaine. Chaque action déclenchée apparaît avec le produit, la date qui l'a déclenchée et le résultat.
5. Une fois que vous avez confirmé que DateCue fait le travail, supprimez l'ancien flux de travail Run Code.

La plupart des migrations prennent moins d'une heure. La partie lente est la vérification, pas la configuration.

Matt Burrell

Fondateur de Ripen Studio. J'ai construit DateCue parce que je continuais à rencontrer ce mur exact et que j'en avais assez de recommander Run Code à des marchands qui ne le méritaient pas. En savoir plus sur Matt.