Un workflow GoHighLevel est relié au compte où il a été construit par des identifiants internes ; déplacez-le sans réécrire ces identifiants et il arrive cassé. Voici exactement ce qui casse, et comment le remappage par nom y remédie.
Dans GoHighLevel, presque tout ce qu'un workflow touche est un élément doté de son propre identifiant interne : un pipeline, une étape de ce pipeline, un utilisateur à qui vous assignez une tâche, un tag, un champ personnalisé, un calendrier, un modèle. Quand vous construisez un workflow, GoHighLevel n'enregistre pas les noms de ces éléments dans la définition ; il enregistre leurs identifiants. Une action « Add tag: Hot Lead » ne stocke pas le texte « Hot Lead » – elle stocke quelque chose comme tag_7c1f…, l'identifiant de ce tag dans ce compte.
Ces identifiants sont propres au compte. Le même tag, créé à la main dans un second compte, y reçoit un identifiant totalement différent. Quand une définition de workflow est extraite d'un compte et déposée dans un autre, chaque identifiant qu'elle porte pointe donc encore vers des éléments qui n'existent que dans le compte source. La destination n'a aucun élément avec cet identifiant : la référence est orpheline. C'est la cause racine de presque tous les signalements « j'ai copié mon workflow et il ne fonctionne plus », et la raison pour laquelle une copie brute du JSON n'est pas un vrai déplacement.
La casse n'est pas aléatoire : elle touche chaque champ du workflow qui contient un id propre au compte plutôt qu'une valeur littérale. Concrètement :
Chacun de ces points est une faille silencieuse. GoHighLevel vous laisse souvent enregistrer un workflow avec une référence orpheline ; il ne fait simplement rien, ou la mauvaise chose, quand un contact atteint cette étape en production. C'est le pire type de panne – invisible tant qu'un vrai contact ne la traverse pas.
ExportGHL Workflows traite le déplacement comme une réconciliation, pas comme une copie. Quand vous déployez un workflow enregistré dans un compte de destination, il lit chaque référence propre au compte dans la définition, retrouve ce qu'elle était dans la source (son nom) et cherche l'élément portant le même nom à destination. L'identifiant source orphelin est alors réécrit avec l'identifiant propre à la destination pour ce pipeline, cette étape, ce tag, cet utilisateur, ce champ, ce calendrier ou ce modèle.
L'association par nom est la bonne clé, car les noms sont ce que les deux comptes partagent réellement. Il est rare d'avoir les mêmes identifiants internes d'un compte à l'autre, mais très fréquent d'avoir un tag « Hot Lead », un « Sales Pipeline » avec une étape « Booked » et un champ personnalisé « Lead Source » dans les deux. ExportGHL parcourt le graphe complet des références – y compris les étapes imbriquées dans leur pipeline et les liens de workflow à workflow – pour qu'une étape remappée atterrisse dans le bon pipeline remappé, et pas dans n'importe quelle étape au nom proche.
Comme il est déployé à destination comme un nouveau workflow, rien de ce que vous avez déjà n'est écrasé. (Vous pouvez choisir d'en mettre un existant à jour, mais c'est un choix explicite, pas le comportement par défaut.) Le résultat est un workflow qui référence les vrais éléments de la destination et fonctionne comme dans la source. Cette page fait partie du guide complet pour exporter les workflows GoHighLevel, le hub pour enregistrer, déplacer et sauvegarder des automatisations entre comptes.
Il est utile de distinguer les deux types d'éléments d'un workflow : les références propres au compte qui doivent être remappées, et les blocs de construction structurels qui passent d'eux-mêmes.
Références remappées par nom. Chacune est associée à l'élément propre à la destination et son identifiant est réécrit. S'il existe une correspondance, elle est préservée ; sinon le workflow reste en brouillon jusqu'à ce que vous la fournissiez ou la mappiez :
Blocs de construction du workflow. La structure de l'automatisation est préservée à l'identique, car elle n'est pas propre au compte. Un bloc n'est mis en brouillon qu'à cause d'une référence propre au compte vers laquelle il pointe – jamais à cause du bloc lui-même :
En bref : la structure et les valeurs littérales (durées d'attente, texte brut des messages, logique des branches) sont préservées intactes, chaque référence propre au compte est remappée par nom quand elle correspond, et tout ce qui n'a pas de correspondance maintient le workflow entier en brouillon plutôt que de le publier cassé.
Parfois un nom n'existe vraiment pas à destination – le tag « Hot Lead » n'y a jamais été créé, ou un utilisateur n'en est pas membre. ExportGHL ne devine pas et ne publie rien qui échouerait en silence. Il signale chaque référence non mappée pour que vous voyiez précisément ce qui manque, et garde le workflow déployé en brouillon. Vous créez ensuite l'élément manquant (ou mappez l'action vers un élément existant) et publiez quand tout est résolu.
Ce comportement de brouillon par défaut est voulu. Le scénario à éviter est un workflow qui paraît actif mais se déclenche mal en silence ; le plus sûr est donc de refuser de publier tant que chaque référence ne pointe pas vers un élément réel.
Des outils comme GHL Workflows Pro, GHL Workflow Importer/Exporter et GHL Workflows JSON Exporter peuvent exporter le JSON d'un workflow et l'importer dans un autre compte. (Super Cloner est parfois rangé avec eux, mais il clone des pages de tunnels et de sites, pas des workflows.) Cela déplace la structure, mais les identifiants qu'elle contient sont copiés tels quels – sans être réconciliés avec la destination. Les références de pipeline, tag, utilisateur, champ et modèle pointent donc toujours vers les identifiants du compte source, et vous voilà de nouveau à réparer chaque étape à la main. Exporter le JSON, c'est les 80 % faciles ; remapper les références propres au compte, ce sont les 20 % difficiles qui font réellement fonctionner le workflow – et c'est la partie qu'ils sautent. Si vous comparez les options, le comparatif des outils de clonage présente leur comportement côte à côte, et le pas-à-pas d'un déplacement unique se trouve dans copier entre comptes.
Les outils propres à GoHighLevel ne comblent pas non plus cette lacune. La duplication native ne fonctionne qu'au sein d'un compte, et les snapshots copient un modèle de compte entier – ils résolvent les références uniquement parce que le snapshot apporte ses propres copies de chaque pipeline, tag et champ, ce qui n'aide en rien quand vous déplacez un workflow vers un compte déjà actif. Le remappage inter-comptes existe précisément pour le cas que GoHighLevel laisse sans réponse.
L'essai gratuit déplace un workflow de bout en bout pour que vous voyiez le remappage et le signalement en brouillon sur votre propre compte avant de dépenser quoi que ce soit. Ensuite, ce sont des crédits à l'usage qui n'expirent jamais, ou une licence Toolkit unique sans abonnement – la page tarifs donne les détails.
Déployez gratuitement un workflow dans un autre compte – voyez chaque pipeline, tag et champ réécrit vers la destination, et tout ce qui n'a pas de correspondance signalé avant la mise en ligne.
Essai gratuit
ExportGHL