Sådan kopierer eller overfører du et workflow mellem GoHighLevel-konti
Skal du flytte GoHighLevel-automatiseringer mellem konti? Platformens indbyggede kopiering når kun underkonti i dit eget bureau, kræver admin og lander som kladde — sådan kopierer eller overfører du et workflow, så det rent faktisk virker i målkontoen.
Kort svar. For at overføre GHL-automatiseringer mellem konti gemmer du workflowet i et skybibliotek i kildekontoen, åbner målkontoen og udruller det som et nyt workflow. Remapping mellem konti kører automatisk — referencer matches via navn, og alt, der ikke matcher, lander som kladde, så intet går live defekt. Det virker på tværs af bureauer og uden bureau-admin-rettigheder — hvilket GoHighLevels indbyggede Copy Workflow to Sub-Account ikke gør.
Du har bygget et godt workflow i én GoHighLevel-konto og vil have det samme til at køre i en anden: en anden underkonto, en klient du lige har onboardet, eller en konto under et andet bureau. Det er kopiering mellem konti. GoHighLevels indbyggede duplikering kloner kun et workflow inden for den konto, det allerede ligger i, og den indbyggede Copy Workflow to Sub-Account når kun andre underkonti i dit eget bureau — for bureau-admins, og den lander som kladde med de fleste referencer ryddet. Skal du flytte på tværs af bureauer, uden admin-rettigheder eller med alle referencer intakte, slipper de indbyggede muligheder op, for et workflow er langt mere kontospecifikt, end det ser ud.
Hvorfor en rå kopi går i stykker i en ny konto
Identiske navne hjælper ikke; id’erne er forskellige, så kopien beholder sin form, men mister sine forbindelser.
Et workflow er ikke et selvstændigt dokument. Næsten ethvert meningsfuldt trin peger på en anden post i kontoen — tilføj et tag, flyt en opportunity til en pipeline-stage, tildel en bruger, opdater et brugerdefineret felt, book ind i en kalender. GoHighLevel gemmer hver af de referencer som et id, der er unikt for den konto, den blev oprettet i, ikke som et navn, du ville genkende.
Så når du tager det rå workflow og smider det ind i en anden konto, peger hvert eneste af de id’er på ingenting. Målkontoen har sine egne pipelines, sine egne tags, sine egne brugere og brugerdefinerede felter — med helt andre id’er, selv om navnene er identiske. Det kopierede workflow har stadig originalens form, men dets triggers og handlinger refererer til poster, der ikke findes i den nye konto. I praksis betyder det, at trin fejler lydløst, at opportunities aldrig flytter sig, og at tags aldrig lander. Workflowet ser fint ud i editoren og er lydløst defekt under kørsel.
Det er præcis det hul, ExportGHL Workflows er bygget til at lukke. I stedet for blindt at tage kilde-id’erne med matcher det hver kontospecifik reference mod målkontoen, før workflowet nogensinde går live.
Kopiflowet, trin for trin
Flytningen går via dit skybibliotek, så de to konti forbliver uafhængige.
Flytningen går via et skybibliotek i stedet for en direkte forbindelse mellem kontoene. Det holder de to konti uafhængige og lader dig senere udrulle det samme gemte workflow til mere end ét mål.
Gem workflowet i kildekontoen. Åbn det workflow, du vil kopiere, og gem det i dit bibliotek. Hvert trin, hver trigger, hvert filter og hver indstilling bliver fanget — intet efterlades, og det oprindelige workflow i kildekontoen røres ikke.
Åbn målkontoens Workflows-side. Skift til den underkonto eller det bureau, du kopierer til, og gå til dets Workflows-område. Det er her, det gemte workflow bliver genopbygget, så du skal være inde i den konto, der skal eje den nye kopi.
Kør det gratis klarhedstjek. Vælg dit gemte workflow, og kør Check — et gratis klarhedstjek, der ikke bruger nogen kredit og ikke udruller noget. Remapping mellem konti kører automatisk ved en udrulning på tværs af konti: ExportGHL læser hver kontospecifik reference i workflowet og leder efter en post med samme navn i målkontoen — pipelinen ”Sales”, tagget ”booked-call”, brugeren, det brugerdefinerede felt, e-mailskabelonen — og Check viser på forhånd, hvad der mappes, hvad auto-create kan bygge, og hvad du selv skal sætte op.
Udrul. ExportGHL genopbygger workflowet i målkontoen som et nyt workflow, med kilde-id’erne skrevet om til målkontoens egne id’er. Det overskriver eller ændrer aldrig et eksisterende workflow, medmindre du bevidst vælger at opdatere et, så der er ingen risiko for at forstyrre aktive automatiseringer i målkontoen.
Match via navn, før du kopierer. Remapping mellem konti parrer referencer ud fra deres navne i hver konto, så et hurtigt tjek af, at målkontoen har en pipeline, et tag eller et brugerdefineret felt med samme navn som i kilden, giver det reneste resultat og færrest ikke-mappede punkter. Hvor nogle mangler, bygger den valgfrie auto-create-kontakt de manglende pipelines (med deres stages) og tags for dig ved udrulningen, så kun skabeloner, kalendere og brugere er tilbage at sætte op i hånden.
Sikkerhedsnettet: kladde ved ikke-mappede referencer
Alt uden navnematch bliver markeret, og workflowet udrulles som en kladde, der aldrig kører.
Navnematch klarer det almindelige tilfælde, men konti glider fra hinanden. Nogle gange har målet simpelthen ikke en tilsvarende post — et tag, der aldrig blev oprettet, en pipeline-stage, der er omdøbt, en bruger, der ikke er på den konto. ExportGHL gætter ikke og peger ikke lydløst de referencer på den nærmeste post. I stedet bliver alt, der ikke kan mappes via navn, markeret, og hvis et workflow stadig har ikke-mappede referencer, udrulles det som en kladde.
En kladde kører aldrig. Du åbner den, ser præcis, hvilke referencer der kræver opmærksomhed, vælger den rigtige målpost eller opretter den manglende og udgiver, når den virkelig er klar. Princippet er enkelt: du ender aldrig med et defekt workflow, der lydløst er live i en klients konto. I værste fald får du en kladde, der kræver et minuts oprydning — ikke en automatisering, der affyres mod de forkerte poster.
Hvorfor ikke bare bruge et snapshot?
Bureauer griber ofte til et snapshot først, og til kopiering mellem konti er det som regel det forkerte værktøj. Et snapshot kopierer en skabelon for hele kontoen, så det er tungt, når man kun skal flytte ét eller få workflows, og det er besværligt at anvende på en konto, der allerede er sat op og live — du risikerer at slæbe ting med, du ikke ville have. ExportGHL Workflows flytter enkelte workflows efter behov ind i konti, der allerede findes, og det er det, kopiering mellem konti reelt kræver. Hvis du vejer de to tilgange op mod hinanden, så se snapshots vs eksport.
Skal du bare bruge det samme workflow igen inden for én konto, så start med klon et workflow. Vil du forstå omskrivningen af id’er dybere, så læs om id-remapping mellem konti, eller se eksportér GoHighLevel-workflows for alle muligheder for at gemme, udrulle og tage backup. Du kan prøve hele flowet uden beregning — dit første workflow flytter du gratis, og derefter kører det på kreditter, der aldrig udløber, eller en engangslicens. Se priser for detaljerne.
Ofte stillede spørgsmål
Kan man kopiere et GoHighLevel-workflow til en anden konto?
Delvist. GoHighLevels indbyggede duplikering kopierer et workflow inden for én underkonto, og Copy Workflow to Sub-Account kan sende et til en anden underkonto i dit eget bureau — men kun for bureau-admins, og det lander som kladde med de fleste referencer ryddet. For at overføre GHL-automatiseringer på tværs af bureauer, som ikke-admin eller med referencerne fuldt remappet er ExportGHL Workflows bygget netop til dette: du gemmer workflowet fra kildekontoen, åbner målkontoen og udruller det dér som et nyt workflow. Ved en udrulning på tværs af konti kører id-remapping mellem konti automatisk og retter de referencer, der ellers ville gå i stykker i den nye konto.
Hvorfor går kopierede workflows i stykker i en ny konto?
Et workflow er fuld af id’er, der kun har betydning inde i den konto, det blev bygget i. Pipelines, stages, tags, brugere, brugerdefinerede felter og e-mailskabeloner er alle gemt som kontospecifikke id’er, ikke som navne. Når det rå workflow lander i en anden konto, peger de id’er på ingenting, så triggers og handlinger refererer til poster, der ikke findes. ExportGHL Workflows matcher hver reference igen via navn i målkontoen og skriver id’erne om, så trinnene opløses korrekt.
Hvad bliver remappet, når jeg kopierer et workflow på tværs af konti?
Remapping mellem konti skriver de id’er om, der er specifikke for kildekontoen: pipelines, pipeline-stages, tags, brugere, brugerdefinerede felter og e-mailskabeloner. Hvert id matches mod posten med samme navn i målkontoen og erstattes med målets id. Alt, der ikke kan matches via navn, efterlades ikke-mappet og markeres, i stedet for lydløst at pege på den forkerte post — og et workflow med ikke-mappede referencer gemmes som kladde.
Skal begge konti være mine?
Du skal have adgang til både kilden og målet. Kopiering virker mellem to vilkårlige underkonti eller bureauer, du kan åbne, uanset om de tilhører dig, dit bureau eller en klient, hvis konto du administrerer. Workflowet gemmes i dit skybibliotek undervejs, så de to konti aldrig er direkte forbundet, og du kan udrulle det samme gemte workflow til flere mål.
ExportGHL