Remapowanie ID workflowa między kontami w GoHighLevel (pipeline, tagi, użytkownicy, pola)

Dlaczego workflow jest związany z kontem, na którym powstał

W GoHighLevel prawie wszystko, czego dotyka workflow, jest rekordem z własnym wewnętrznym ID: pipeline, etap w tym pipeline, użytkownik, któremu przypisujesz zadanie, tag, pole niestandardowe, kalendarz, szablon. Gdy budujesz workflow, GoHighLevel nie zapisuje w jego definicji nazw tych rekordów. Zapisuje ich ID. Akcja „Add tag: Hot Lead” nie przechowuje tekstu „Hot Lead” — przechowuje coś w rodzaju tag_7c1f…, czyli ID tego tagu na tym koncie.

Te ID są powiązane z kontem. Ten sam tag utworzony ręcznie na drugim koncie dostaje tam zupełnie inne ID. Gdy więc definicja workflowa zostaje wyjęta z jednego konta i wrzucona na drugie, każde ID, które niesie, nadal wskazuje rekordy istniejące wyłącznie na koncie źródłowym. Konto docelowe nie ma rekordu o takim ID, więc odwołanie wisi w powietrzu. To źródło niemal każdego zgłoszenia „skopiowałem workflow i przestał działać” i powód, dla którego surowa kopia JSON nie jest prawdziwym przeniesieniem.

Dokładnie które pola się psują

Uszkodzenia nie są losowe — dotyczą każdego pola w workflowie, które przechowuje ID powiązane z kontem, a nie wartość dosłowną. W praktyce oznacza to:

• Pipeline i etap. Akcje „Create / update opportunity” i „move to stage” odwołują się do ID pipeline i ID etapu w nim. Oba są specyficzne dla konta, a ID etapu bez swojego pipeline nic nie znaczy.
• Użytkownik / osoba przypisana. „Assign to user” i kroki round-robin odwołują się do ID użytkowników. Ta sama osoba ma na każdym koncie inne ID i może w ogóle nie być członkiem konta docelowego.
• Tagi. Akcje dodawania i usuwania tagów oraz każdy wyzwalacz lub gałąź if/else oparte na tagach działają na ID tagów.
• Pola niestandardowe. Wszystko, co czyta lub zapisuje pole niestandardowe — w tym warunki rozgałęziające się według wartości pola — wskazuje ID tego pola.
• Kalendarze. Akcje spotkań i rezerwacji odwołują się do ID kalendarza.
• Szablony e-mail i SMS. Kroki „Send email” lub „Send SMS”, które używają zapisanego szablonu, odwołują się do ID tego szablonu.
• Wartości niestandardowe. Pola scalania i wartości niestandardowe na poziomie konta są rozwiązywane po ID i same w sobie nie są przenośne.
• Odwołania między workflowami. Kroki „Go to another workflow” lub „remove from workflow” wskazują ID sąsiedniego workflowa — który sam musi zostać przeniesiony i przemapowany, bo inaczej nie ma na co wskazywać.

Każde z nich to cichy punkt awarii. GoHighLevel często pozwala zapisać workflow z wiszącym odwołaniem; po prostu nic się nie dzieje albo dzieje się coś złego, gdy kontakt na produkcji dotrze do tego kroku. To najgorszy rodzaj błędu — niewidoczny, dopóki nie przejdzie przez niego prawdziwy kontakt.

Jak ExportGHL dopasowuje według nazw i przepisuje ID

ExportGHL Workflows traktuje przeniesienie jako uzgodnienie, a nie kopię. Gdy wdrażasz zapisany workflow na koncie docelowym, odczytuje każde odwołanie powiązane z kontem w definicji, sprawdza, czym to odwołanie było w źródle (jego nazwę) i szuka na koncie docelowym rekordu o tej samej nazwie. Wiszące ID źródła jest następnie przepisywane na własne ID konta docelowego dla tego pipeline, etapu, tagu, użytkownika, pola, kalendarza lub szablonu.

Dopasowanie według nazw to właściwy klucz, bo nazwy to to, co oba konta faktycznie współdzielą. Rzadko zdarza się, by miały te same wewnętrzne ID, ale bardzo często na obu są tag „Hot Lead”, „Sales Pipeline” z etapem „Booked” i pole niestandardowe „Lead Source”. ExportGHL przechodzi cały graf odwołań — w tym etapy zagnieżdżone w swoim pipeline i linki między workflowami — więc przemapowany etap trafia do właściwego przemapowanego pipeline, a nie do dowolnego etapu o podobnej nazwie.

Ponieważ wdraża się na koncie docelowym jako nowy workflow, nic, co już masz, nie zostaje nadpisane. (Możesz wybrać aktualizację istniejącego, ale to świadomy wybór, a nie domyślne zachowanie.) Efektem jest workflow odwołujący się do prawdziwych rekordów konta docelowego i działający tak samo jak w źródle. Ta strona jest częścią kompletnego poradnika eksportu workflowów GoHighLevel — centrum wiedzy o zapisywaniu, przenoszeniu i tworzeniu kopii zapasowych automatyzacji między kontami.

Co ExportGHL remapuje, zachowuje i zostawia jako szkic

Warto rozdzielić dwa rodzaje rzeczy w workflowie: odwołania powiązane z kontem, które trzeba przemapować, oraz strukturalne elementy składowe, które przechodzą same.

Odwołania remapowane według nazw. Każde z nich jest dopasowywane do własnego rekordu konta docelowego, a ID zostaje przepisane. Jeśli dopasowanie istnieje, jest zachowane; jeśli nie, workflow zostaje szkicem, dopóki nie dostarczysz lub nie zmapujesz brakującego elementu:

• Pipeline
• Etapy (w nadrzędnym pipeline)
• Tagi
• Użytkownicy i osoby przypisane
• Pola niestandardowe
• Kalendarze
• Szablony e-mail i SMS

Elementy składowe workflowa. Struktura automatyzacji jest zachowana dokładnie, bo nie jest powiązana z kontem. Element składowy staje się szkicem tylko z powodu wskazywanego przez niego odwołania powiązanego z kontem — nigdy z powodu samego elementu:

• Wyzwalacze
• Filtry wyzwalaczy i akcji
• Akcje, w kolejności
• Kroki oczekiwania i timery
• Gałęzie if/else
• Cele

Krótko: struktura i wartości dosłowne (czasy oczekiwania, zwykły tekst wiadomości, logika gałęzi) są zachowane w całości, każde odwołanie powiązane z kontem jest remapowane według nazwy, gdy się zgadza, a wszystko bez dopasowania trzyma cały workflow w szkicu zamiast publikować go zepsutego.

Co się dzieje, gdy odwołania nie da się zmapować

Czasem nazwa naprawdę nie istnieje na koncie docelowym — tag „Hot Lead” nigdy tam nie powstał albo użytkownik nie jest członkiem. ExportGHL nie zgaduje i nie publikuje czegoś, co zawiedzie po cichu. Oznacza każde niedopasowane odwołanie, żebyś widział dokładnie, czego brakuje, i zachowuje wdrożony workflow jako szkic. Potem tworzysz brakujący rekord (lub mapujesz akcję na istniejący) i publikujesz, gdy wszystko się rozwiązuje.

Takie domyślne zachowanie — szkic — jest celowe. Unikasz workflowa, który wygląda na działający, a po cichu odpala się błędnie, więc bezpieczny ruch to odmowa publikacji, dopóki każde odwołanie nie wskazuje czegoś prawdziwego.

Dlaczego konkurenci oparci tylko na JSON zostawiają to zepsute

Narzędzia takie jak GHL Workflows Pro, GHL Workflow Importer/Exporter i GHL Workflows JSON Exporter potrafią wyeksportować JSON workflowa i zaimportować go na inne konto. (Super Cloner bywa wrzucany do tego samego worka, ale klonuje strony lejków i witryn, a nie workflowy.) To przenosi strukturę, ale ID w środku są kopiowane dosłownie — nie są uzgadniane z kontem docelowym. Odwołania do pipeline, tagów, użytkowników, pól i szablonów nadal wskazują ID konta źródłowego i znów naprawiasz każdy krok ręcznie. Eksport JSON to łatwe 80%; remapowanie odwołań powiązanych z kontem to trudne 20%, które naprawdę sprawia, że workflow działa — i właśnie tę część te narzędzia pomijają. Jeśli porównujesz opcje, porównanie klonatorów zestawia ich zachowanie obok siebie, a instrukcja pojedynczego przeniesienia jest w poradniku kopiowanie między kontami.

Własne narzędzia GoHighLevel też nie zamykają tej luki. Natywne duplikowanie działa tylko w obrębie jednego konta, a snapshoty kopiują szablon całego konta — odwołania rozwiązują się tylko dlatego, że snapshot przynosi własne kopie każdego pipeline, tagu i pola, co nie pomaga, gdy przenosisz jeden workflow na konto, które już działa. Remapowanie między kontami istnieje właśnie dla przypadku, którego GoHighLevel nie obejmuje.

Najpierw wypróbuj na prawdziwym workflowie

Bezpłatny okres próbny przenosi jeden workflow od początku do końca, żebyś zobaczył remapowanie i oznaczanie szkiców na własnym koncie, zanim cokolwiek wydasz. Potem są kredyty płatne w miarę użycia, które nie wygasają, albo jednorazowa licencja Toolkit bez abonamentu — szczegóły w cenniku.

Najczęstsze pytania