GoHighLevelのアカウント間ワークフローIDリマップ（パイプライン、タグ、ユーザー、フィールド）

ワークフローが作成されたアカウントに縛られている理由

GoHighLevelの内部では、ワークフローが扱うほぼすべてのものが、独自の内部IDを持つレコードです。パイプライン、そのパイプライン内のステージ、タスクを割り当てるユーザー、タグ、カスタムフィールド、カレンダー、テンプレート。ワークフローを作るとき、GoHighLevelはそれらのレコードの名前をワークフロー定義に保存しません。保存するのはIDです。「タグを追加：Hot Lead」というアクションは「Hot Lead」という文字列を保存せず、そのアカウント内のそのタグのIDであるtag_7c1f…のようなものを保存します。

これらのIDはアカウント固有です。同じタグを2つ目のアカウントで手作業で作ると、そこでは完全に別のIDが付きます。そのため、ワークフロー定義をあるアカウントから取り出して別のアカウントに入れると、含まれているすべてのIDは、コピー元にしか存在しないレコードを指したままになります。移行先にはそのIDのレコードがないので、参照は宙に浮きます。これが「ワークフローをコピーしたら動かなくなった」という報告のほぼすべての根本原因であり、JSONをそのままコピーしても本当の移行にならない理由です。

具体的にどの項目が壊れるのか

壊れ方はランダムではありません。リテラル値ではなく、アカウント固有のIDを保持するワークフロー内のすべての項目です。具体的には次のとおりです。

• パイプラインとステージ。「商談を作成／更新」や「ステージに移動」のアクションは、パイプラインIDとその中のステージIDを参照します。どちらもアカウント固有で、ステージIDは親のパイプラインがなければ意味を持ちません。
• ユーザー／担当者。「ユーザーに割り当て」やラウンドロビンのステップはユーザーIDを参照します。同じ人でもアカウントごとにIDが異なり、移行先のメンバーですらない場合もあります。
• タグ。タグの追加・削除アクション、タグベースのトリガーやif/else分岐は、すべてタグIDで動作します。
• カスタムフィールド。カスタムフィールドを読み書きするもの（フィールドの値で分岐する条件を含む）は、そのフィールドのIDを指しています。
• カレンダー。予約やアポイントメントのアクションはカレンダーIDを参照します。
• メール・SMSテンプレート。保存済みテンプレートを使う「メール送信」や「SMS送信」のステップは、そのテンプレートのIDを参照します。
• カスタム値。マージフィールドとアカウントレベルのカスタム値はIDで解決され、それ単体では持ち運べません。
• ワークフロー間の参照。「別のワークフローへ移動」や「ワークフローから削除」のステップは、兄弟ワークフローのIDを指します。そのワークフロー自体も移行してリマップしておかなければ、指す先がありません。

これらはどれも、静かに失敗するポイントです。GoHighLevelは、宙に浮いた参照を持つワークフローでも保存できてしまうことが多く、本番でコンタクトがそのステップに到達したときに、何も起きないか、間違ったことが起きるだけです。実際のコンタクトが通過するまで気付けない、最悪の種類の不具合です。

ExportGHLが名前で照合してIDを書き換える仕組み

ExportGHL Workflowsは、移行をコピーではなく照合として扱います。保存したワークフローを移行先のアカウントにデプロイすると、定義内のアカウント固有の参照をすべて読み取り、コピー元でその参照が何だったか（その名前）を調べ、移行先で同じ名前のレコードを探します。宙に浮いたコピー元のIDは、移行先のそのパイプライン、ステージ、タグ、ユーザー、フィールド、カレンダー、テンプレートの固有IDに書き換えられます。

名前を照合のキーにするのが正解です。2つのアカウントが実際に共有しているのは名前だからです。アカウント間で同じ内部IDを持つことはまずありませんが、「Hot Lead」というタグ、「Booked」ステージのある「Sales Pipeline」、「Lead Source」というカスタムフィールドは、どちらにもあることがよくあります。ExportGHLは、パイプライン内にネストされたステージやワークフロー間リンクを含む参照グラフ全体をたどるので、リマップされたステージは、名前が似ているだけの別のステージではなく、正しくリマップされたパイプラインの中に入ります。

移行先には新しいワークフローとしてデプロイされるため、既存のものが上書きされることはありません（既存のものを更新することも選べますが、それは明示的な選択で、既定ではありません）。その結果、移行先の実際のレコードを参照し、コピー元と同じように動作するワークフローが手に入ります。このページは、アカウント間でオートメーションを保存・移動・バックアップするためのハブ、GoHighLevelワークフローのエクスポート完全ガイドの一部です。

ExportGHLがリマップするもの、保持するもの、下書きにするもの

ワークフロー内には2種類のものがあります。リマップが必要なアカウント固有の参照と、そのまま引き継がれる構造上の構成要素です。

名前でリマップされる参照。それぞれ移行先の固有のレコードと照合され、IDが書き換えられます。一致するものがあれば保持され、なければ、自分で用意するかマッピングするまでワークフローは下書きのままになります。

• パイプライン
• ステージ（親パイプライン内）
• タグ
• ユーザーと担当者
• カスタムフィールド
• カレンダー
• メール・SMSテンプレート

ワークフローの構成要素。オートメーションの構造は、アカウント固有ではないため、そのまま保持されます。構成要素が下書きになるのは、それが指すアカウント固有の参照が原因のときだけで、構成要素そのものが原因になることはありません。

• トリガー
• トリガーとアクションのフィルター
• アクション（順序どおり）
• 待機ステップとタイマー
• if/else分岐
• ゴール

要するに、構造とリテラル値（待機時間、プレーンなメッセージ本文、分岐ロジック）はそのまま保持され、アカウント固有の参照は一致すれば名前でリマップされ、一致しないものがあればワークフロー全体が壊れた状態で公開されず下書きで保留されます。

参照をマッピングできないときの動作

移行先に、その名前が本当に存在しない場合もあります。「Hot Lead」タグがそこで作られていない、ユーザーがメンバーではない、など。ExportGHLは推測せず、気付かないうちに失敗するものを公開もしません。一致しない参照をすべてフラグ付きで示すので、何が足りないのかを正確に確認でき、デプロイされたワークフローは下書きのままになります。そのうえで、不足しているレコードを作成する（またはアクションを既存のものにマッピングする）と、すべてが解決された時点で公開できます。

この下書きを既定とする動作は意図的です。避けたいのは、稼働しているように見えて静かに誤作動するワークフローなので、すべての参照が実在するものを指すまで公開を拒否するのが安全な選択です。

JSONのみの競合ツールでは壊れたままになる理由

GHL Workflows Pro、GHL Workflow Importer/Exporter、GHL Workflows JSON Exporterなどのツールは、ワークフローのJSONをエクスポートして別のアカウントにインポートできます（Super Clonerもまとめて語られることがありますが、これはワークフローではなくファネルやWebサイトのページを複製するものです）。構造は移りますが、その中のIDはそのままコピーされ、移行先と照合されません。そのため、パイプライン、タグ、ユーザー、フィールド、テンプレートの参照は、コピー元のアカウントのIDを指したままで、結局すべてのステップを手作業で直すことになります。JSONのエクスポートは簡単な8割にすぎず、アカウント固有の参照をリマップするのが、ワークフローを実際に動かす難しい2割です。そして、それこそが彼らが省略している部分です。選択肢を比べるなら、複製ツールの比較で動作を並べて確認でき、1回の移行の手順はアカウント間のコピーにあります。

GoHighLevel自身のツールでも、このギャップは埋まりません。標準の複製は1つのアカウント内でしか機能せず、スナップショットはアカウント全体のテンプレートをコピーします。スナップショットで参照が解決されるのは、すべてのパイプライン、タグ、フィールドの独自のコピーも一緒に持ち込むからにすぎず、すでに稼働中のアカウントに1つのワークフローを移す場合には役に立ちません。アカウント間リマップは、GoHighLevelがカバーしていないこのケースのために存在します。

まずは実際のワークフローで試す

無料トライアルでは、ワークフロー1つを最初から最後まで移行できるので、費用をかける前に、自分のアカウントでリマップと下書きのフラグ付けを確認できます。その後は、有効期限のない従量課金クレジットか、サブスクリプション不要の買い切りToolkitライセンスです。詳細は料金ページをご覧ください。

よくある質問