Automatiser les commandes provisoires avec Shopify Flow

Utilisez des tâches Kanbanify distinctes pour déplacer une commande provisoire ouverte, définir son marqueur ou attribuer un membre existant de votre équipe. Les tâches de commandes provisoires diffèrent des tâches de commandes : Draft order stage changed fournit un ID de commande provisoire au format texte, et non la référence de commande native de Shopify Flow.

Avant de commencer

• Installez Shopify Flow et Kanbanify dans la même boutique, activez le tableau des commandes provisoires et accordez à Kanbanify l’accès demandé aux commandes provisoires.
• Préparez deux étapes définies par le marchand sur ce tableau. Dans le menu des actions de l’étape de destination, utilisez Copier l’ID de l’étape (également disponible dans les paramètres Kanbanify). Utilisez l’ID, pas le nom de l’étape. Flow ne propose pas de sélecteur d’étapes Kanbanify.
• Pour une attribution, choisissez une personne déjà présente dans Paramètres → Liste de l’équipe. Utilisez son e-mail dans la liste, pas son nom d’affichage ni un identifiant de compte du personnel Shopify. L’action n’ajoute pas de membre et n’envoie pas d’invitation.
• Testez avec une commande provisoire ouverte et jetable avant d’activer une automatisation importante. La disponibilité dépend de la version de Kanbanify déployée dans votre boutique.

Relier le déclencheur à chaque action

1. Dans Shopify Flow, créez un flux de travail avec le déclencheur Kanbanify Draft order stage changed. Il démarre lors du placement initial sur le tableau des commandes provisoires ou d’un véritable déplacement entre étapes, et non à chaque modification de la commande.
2. Ajoutez des conditions limitant le flux à votre tableau de commandes provisoires et à l’ID de l’étape cible du déclencheur. Pour un premier test, limitez-le aussi à un seul ID de commande provisoire jetable.
3. Ajoutez une ou plusieurs actions Kanbanify ci-dessous. Dans le champ ID de commande provisoire (draft_order_id) de chaque action, insérez la variable draftOrderId du déclencheur à l’aide du sélecteur de variables de Flow. Ne saisissez pas le nom de variable comme texte littéral.

Un ID décimal positif ou gid://shopify/DraftOrder/<id> est accepté. Un GID de commande, un nom de commande provisoire tel que #D123, une URL d’administration, une entrée vide ou l’ID d’une autre ressource ne le sont pas. La commande provisoire doit toujours être ouverte ou avoir une facture envoyée. Les étapes supprimées, les étapes système, les étapes d’un autre tableau et un contexte de tableau invalide sont rejetés avant toute modification. Seule une absence confirmée d’association au tableau peut utiliser le tableau de commandes provisoires configuré ; des métadonnées enregistrées incomplètes ou incorrectes ne sont pas remplacées silencieusement.

Exemple sans boucle

Pour une commande provisoire de test, conditionnez sur ID d’étape cible = ID de votre étape d’entrée. Enchaînez :

1. Définissez son étape sur un ID d’étape de destination différent.
2. Définissez son marqueur sur Teal / Diagonal stripe.
3. Attribuez un membre de l’équipe de test existant par e-mail.

Liez le draftOrderId du déclencheur original aux trois actions. Le second événement d’étape nomme la destination et doit donc échouer à la condition de l’étape d’entrée au lieu de boucler. L’action de marqueur s’exécute après l’action d’étape et remplace tout marqueur par défaut de destination. Ces actions sont indépendantes, pas une transaction unique : vérifiez le résultat de chaque action.

Activez le flux de test, déplacez cette commande provisoire dans l’étape d’entrée, puis consultez l’historique d’exécution de Flow et rechargez Kanbanify pour vérifier l’étape de destination, le marqueur et le responsable de cette même commande. Vérifiez les résultats des actions, pas seulement le démarrage d’un flux. Désactivez ou supprimez le flux de test avant de supprimer ses données jetables. Évitez les règles qui déplacent une commande provisoire dans les deux sens.

Signification du succès et des nouvelles tentatives

• Le succès de l’action d’étape confirme uniquement le placement enregistré. Un marqueur par défaut de destination est enregistré avec l’étape ; sans valeur par défaut, le marqueur existant est conservé. Le responsable et les métadonnées sans rapport ne sont pas modifiés.
• Le nettoyage du tri manuel, les étiquettes d’étape automatiques et l’envoi du déclencheur en aval sont effectués au mieux après cet enregistrement. Leurs échecs n’annulent pas l’étape et ne font pas échouer l’action. Si l’ajout de la nouvelle étiquette échoue, la suppression des anciennes est ignorée ; si leur suppression échoue, les deux étiquettes peuvent rester. Vérifiez la carte et les étiquettes lorsque cela compte.
• Une demande valide de l’étape déjà enregistrée réussit sans modification. Elle ne répare pas les précédents échecs de tri ou d’étiquettes et ne rejoue pas un déclencheur, y compris après une réponse d’enregistrement perdue.
• Les actions de marqueur ou de responsable valides répétées écrivent sans risque les mêmes valeurs. Elles ne modifient ni l’étape, ni les étiquettes, ni le placement manuel. La dernière écriture réussie prévaut.
• Un échec de validation ou de recherche fait échouer l’action avant toute écriture. Un enregistrement principal rejeté conserve l’état précédent ; une connexion perdue après l’envoi peut masquer une écriture terminée. Rechargez la commande provisoire avant de décider quoi faire. Il n’y a ni annulation ni compensation automatique.
• Un déclencheur envoyé ne prouve pas qu’un flux de travail a été exécuté. Kanbanify ne garantit ni la livraison, ni une exécution exactement une fois, ni la déduplication concurrente, ni la relecture automatique.

Les déplacements sur le tableau et les actions d’étape de commande existantes ont des limites d’échec différentes. Un déplacement sur le tableau peut enregistrer son étape tout en échouant au nettoyage obligatoire du tri (sans déclencheur) ou aux étiquettes (après une tentative de déclencheur de la ressource). L’action existante d’étape de commande peut s’arrêter avant son déclencheur après une étape enregistrée si le nettoyage du tri ou une requête d’étiquette levée échoue. Une nouvelle tentative sur la même étape ne répare ni ne rejoue ces envois. N’appliquez pas la règle de succès du placement de l’action Draft à ces autres points d’entrée.

Lorsqu’une commande provisoire devient une commande

Terminer une commande provisoire dans Shopify ne déclenche jamais le déclencheur Draft. Normalement, Kanbanify copie son marqueur et son responsable, place la commande obtenue dans la première étape du tableau de commandes, gère les étiquettes d’étape et le nettoyage de la commande provisoire, puis tente une fois le déclencheur de changement d’étape de commande.

Une limite de nouvelle tentative subsiste : si l’étape de la commande est enregistrée mais que la gestion des étiquettes de conversion ou le nettoyage échoue avant l’envoi, une nouvelle tentative réussie peut constater cette étape enregistrée et envoyer zéro déclencheur de commande. La conversion n’offre aucune garantie de récupération ou de relecture. Vérifiez la commande résultante et l’historique Flow ; ne comptez pas sur la conversion pour des notifications garanties une seule fois.

Séparer les flux de commandes et de commandes provisoires

Les noms de tâches de commande existants et les liaisons de commande natives restent disponibles. Le déclencheur de commande fournit en plus orderName et orderAdminUrl ; ses champs originaux restent inchangés. Les demandes d’étape identique sur le tableau de commandes ne lancent plus Flow. Conservez un flux de commande existant comme vérification indépendante lorsque vous introduisez l’automatisation Draft.

Le déclencheur Draft offre l’ID, le nom et l’URL d’administration de la commande provisoire, le tableau, les étapes source/cible et le contexte de responsable capturé. Le texte facultatif peut être vide et les positions indisponibles sont -1 ; le placement initial n’a pas d’étape source. Il n’expose ni référence Draft typée, ni données Draft arbitraires, ni notes, ni étiquettes. Les champs de responsable capturés ne sont pas actualisés par une attribution ultérieure dans le flux.

Il n’existe pas d’action Draft combinée, de transfert de tableau ni d’action Draft distincte pour le tri, les étiquettes, la finalisation, la date limite ou les notes. Le marqueur, le responsable, la réorganisation/le tri, les étiquettes, les notes, la finalisation et la conversion ne démarrent pas le déclencheur d’étape Draft. La finalisation des commandes provisoires depuis Kanbanify ou ses actions Flow n’est pas prise en charge.