Ein GoHighLevel-Workflow ist über interne IDs an den Account gebunden, in dem er gebaut wurde; verschieben Sie ihn, ohne diese IDs umzuschreiben, kommt er defekt an. Hier steht genau, was bricht und wie das namensbasierte Remapping es behebt.
In GoHighLevel ist fast alles, was ein Workflow berührt, ein Datensatz mit eigener interner ID: eine Pipeline, eine Stage in dieser Pipeline, ein Benutzer, dem Sie eine Aufgabe zuweisen, ein Tag, ein benutzerdefiniertes Feld, ein Kalender, eine Vorlage. Beim Bau eines Workflows speichert GoHighLevel in der Workflow-Definition nicht die Namen dieser Datensätze, sondern ihre IDs. Eine Aktion „Add tag: Hot Lead“ speichert nicht den Text „Hot Lead“, sondern etwas wie tag_7c1f… – die ID dieses Tags in diesem Account.
Diese IDs gelten nur innerhalb eines Accounts. Derselbe Tag, von Hand in einem zweiten Account angelegt, erhält dort eine völlig andere ID. Wird eine Workflow-Definition aus einem Account herausgelöst und in einen anderen eingefügt, zeigt jede mitgeführte ID noch auf Datensätze, die nur im Quellaccount existieren. Das Ziel hat keinen Datensatz mit dieser ID, der Verweis läuft also ins Leere. Das ist die Ursache nahezu jeder Meldung „Ich habe meinen Workflow kopiert, und er funktioniert nicht mehr“ – und der Grund, warum eine Roh-Kopie des JSON kein echter Umzug ist.
Der Bruch ist nicht zufällig – er betrifft jedes Feld im Workflow, das eine accountspezifische ID statt eines Literalwerts enthält. In der Praxis sind das:
Jede dieser Stellen ist ein stiller Ausfallpunkt. GoHighLevel lässt Sie einen Workflow oft mit einem ins Leere zeigenden Verweis speichern; er tut dann nichts oder das Falsche, wenn ein Kontakt in der Produktion diesen Schritt erreicht. Das ist die schlimmste Art von Fehler – unsichtbar, bis ein echter Kontakt hindurchläuft.
ExportGHL Workflows behandelt den Umzug als Abgleich, nicht als Kopie. Wenn Sie einen gespeicherten Workflow in einem Zielaccount bereitstellen, liest es jeden accountspezifischen Verweis der Definition, ermittelt, was dieser Verweis in der Quelle war (seinen Namen), und findet im Ziel den Datensatz mit dem passenden Namen. Die ins Leere zeigende Quell-ID wird dann auf die eigene ID des Ziels für diese Pipeline, Stage, diesen Tag, Benutzer, dieses Feld, diesen Kalender oder diese Vorlage umgeschrieben.
Der Abgleich per Namen ist der richtige Schlüssel, weil Namen das sind, was beide Accounts tatsächlich gemeinsam haben. Gleiche interne IDs über Accounts hinweg haben Sie selten, aber sehr oft einen Tag „Hot Lead“, eine „Sales Pipeline“ mit einer Stage „Booked“ und ein benutzerdefiniertes Feld „Lead Source“ in beiden. ExportGHL durchläuft den gesamten Verweisgraphen – einschließlich der in ihrer Pipeline verschachtelten Stages und der Workflow-zu-Workflow-Verknüpfungen –, sodass eine neu zugeordnete Stage in der richtigen neu zugeordneten Pipeline landet und nicht in irgendeiner Stage mit ähnlichem Namen.
Da es im Ziel als neuer Workflow bereitgestellt wird, wird nichts Vorhandenes überschrieben. (Sie können einen bestehenden aktualisieren, aber das ist eine bewusste Entscheidung, nicht der Standard.) Das Ergebnis ist ein Workflow, der auf die echten Datensätze des Ziels verweist und genauso läuft wie in der Quelle. Diese Seite gehört zum kompletten Ratgeber zum Exportieren von GoHighLevel-Workflows, dem Hub zum Speichern, Verschieben und Sichern von Automatisierungen über Accounts hinweg.
Es hilft, zwei Arten von Elementen in einem Workflow zu trennen: die accountspezifischen Verweise, die neu zugeordnet werden müssen, und die strukturellen Bausteine, die von allein mitkommen.
Per Namen neu zugeordnete Verweise. Jeder davon wird mit dem eigenen Datensatz des Ziels abgeglichen, und die ID wird umgeschrieben. Gibt es einen Treffer, bleibt er erhalten; gibt es keinen, bleibt der Workflow ein Entwurf, bis Sie ihn bereitstellen oder zuordnen:
Workflow-Bausteine. Die Struktur der Automatisierung bleibt genau erhalten, weil sie nicht accountspezifisch ist. Ein Baustein wird nur wegen eines accountspezifischen Verweises, auf den er zeigt, zum Entwurf – nie wegen des Bausteins selbst:
Kurz gesagt: Struktur und Literalwerte (Wartezeiten, einfacher Nachrichtentext, Zweiglogik) bleiben unversehrt, jeder accountspezifische Verweis wird bei einem Treffer per Namen neu zugeordnet, und alles Nicht-Zugeordnete hält den ganzen Workflow im Entwurf, statt ihn defekt zu veröffentlichen.
Manchmal existiert ein Name im Ziel tatsächlich nicht – der Tag „Hot Lead“ wurde dort nie angelegt, oder ein Benutzer ist kein Mitglied. ExportGHL rät nicht und veröffentlicht nichts, was stillschweigend scheitern würde. Es markiert jeden nicht zugeordneten Verweis, damit Sie genau sehen, was fehlt, und belässt den bereitgestellten Workflow als Entwurf. Dann legen Sie den fehlenden Datensatz an (oder ordnen die Aktion einem vorhandenen zu) und veröffentlichen, sobald alles aufgelöst ist.
Dieses Entwurf-als-Standard-Verhalten ist Absicht. Der Fehlerfall, den Sie vermeiden, ist ein Workflow, der live aussieht, aber still falsch feuert – sicher ist es daher, die Veröffentlichung zu verweigern, bis jeder Verweis auf etwas Reales zeigt.
Tools wie GHL Workflows Pro, GHL Workflow Importer/Exporter und GHL Workflows JSON Exporter können das JSON eines Workflows exportieren und in einen anderen Account importieren. (Super Cloner wird manchmal dazugezählt, klont aber Funnel- und Website-Seiten, keine Workflows.) Das verschiebt die Struktur, doch die IDs darin werden wortwörtlich kopiert – nicht mit dem Ziel abgeglichen. Verweise auf Pipeline, Tag, Benutzer, Feld und Vorlage zeigen also weiter auf die IDs des Quellaccounts, und Sie reparieren wieder jeden Schritt von Hand. Das JSON zu exportieren sind die einfachen 80 %; das Neuzuordnen der accountspezifischen Verweise sind die schweren 20 %, die den Workflow wirklich zum Laufen bringen – und genau diesen Teil überspringen sie. Wenn Sie Optionen abwägen, legt der Cloner-Vergleich das Verhalten nebeneinander dar, und die Schritt-für-Schritt-Anleitung für einen einzelnen Umzug steht unter Zwischen Accounts kopieren.
Auch GoHighLevels eigene Werkzeuge schließen diese Lücke nicht. Natives Duplizieren funktioniert nur innerhalb eines Accounts, und Snapshots kopieren eine Vorlage für den ganzen Account – sie lösen Verweise nur deshalb auf, weil der Snapshot eigene Kopien aller Pipelines, Tags und Felder mitbringt, was nichts nützt, wenn Sie einen Workflow in einen bereits laufenden Account verschieben. Das Account-übergreifende Remapping gibt es genau für den Fall, den GoHighLevel offenlässt.
Die kostenlose Testversion verschiebt einen Workflow von Anfang bis Ende, sodass Sie Remapping und Entwurfs-Markierung in Ihrem eigenen Account sehen, bevor Sie etwas bezahlen. Danach gelten nutzungsbasierte Credits, die nie verfallen, oder eine einmalige Toolkit-Lizenz ohne Abo – Details auf der Seite Preise.
Stellen Sie einen Workflow kostenlos in einem anderen Account bereit – sehen Sie, wie jede Pipeline, jeder Tag und jedes Feld auf das Ziel umgeschrieben wird und alles Nicht-Zugeordnete vor dem Livegang markiert wird.
Gratis starten
ExportGHL