Din Bitrix24-chatt blir inte ”fullt upp”. Den blir rörig. Ett missat meddelande blir en uppföljning du aldrig skickar – och sedan en kund som tyst försvinner.
Supportansvariga märker det först, eftersom de hålls ansvariga för svarstider. En småföretagare ser det som sena kvällar och konstant kollande. Och om du är drift-/ops-ansvarig som äger verktygen sitter du fast med att underhålla en Bitrix24 Telegram-bot-setup som kraschar så fort en token ändras.
Det här arbetsflödet gör Bitrix24 webhook-händelser till verifierade, automatiserade svar, plus valfria Telegram-varningar. Du får se hur det förhindrar missade chattar, håller installationer stabila och minskar triage till de ärenden som faktiskt behöver en människa.
Så fungerar automatiseringen
Hela n8n-flödet, från trigger till slutlig output:
n8n Workflow Template: Bitrix24 + Telegram: direkta botsvar, mindre triage
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Bitrix24 Handler"]
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Credentials", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Validate Token", pos: "b", h: 48 }
n3@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Route Event", pos: "b", h: 48 }
n4@{ icon: "mdi:code-braces", form: "rounded", label: "Process Message", pos: "b", h: 48 }
n5@{ icon: "mdi:code-braces", form: "rounded", label: "Process Join", pos: "b", h: 48 }
n6@{ icon: "mdi:code-braces", form: "rounded", label: "Process Install", pos: "b", h: 48 }
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Register Bot"]
n8["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Send Message"]
n9["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Send Join Message"]
n10@{ icon: "mdi:cog", form: "rounded", label: "Process Delete", pos: "b", h: 48 }
n11["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Success Response"]
n12["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>Error Response"]
n1 --> n2
n3 --> n4
n3 --> n5
n3 --> n6
n3 --> n10
n5 --> n9
n7 --> n11
n8 --> n11
n10 --> n11
n2 --> n3
n2 --> n12
n6 --> n7
n4 --> n8
n0 --> n1
n9 --> n11
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n2,n3 decision
class n0,n7,n8,n9,n11,n12 api
class n4,n5,n6 code
classDef customIcon fill:none,stroke:none
class n0,n7,n8,n9,n11,n12 customIcon
Problemet: Bitrix24-chattar skapar konstant triage
När Bitrix24-meddelanden kommer in snabbt är den verkliga kostnaden inte skrivandet. Det är kontextbytena. Någon måste kolla chatten, avgöra om meddelandet är äkta, förstå vilken typ av händelse det är (nytt meddelande, anslutning, installation, borttagning) och sedan svara eller routa det vidare. Och om din bot-integration är ens lite skör hamnar du i den värsta kombon: kunder väntar och ditt team felsöker. En enda utgången token kan få boten att se ”online” ut samtidigt som den misslyckas i tysthet – vilket är det farligaste felläget.
Det bygger snabbt på. Här är var friktionen brukar dyka upp i vardagen.
- Handläggare slösar tid på att svara på samma inledande frågor i stället för att hantera riktiga problem.
- Säkerhet viftas bort eftersom token-validering känns som ”extra jobb”, ända tills något går sönder.
- Installations- och anslutningshändelser ignoreras, så nya chattar startar utan välkomstmeddelande eller korrekt bot-registrering.
- När en integration fallerar får du reda på det via en arg kund – inte via en intern varning.
Lösningen: Verifierade Bitrix24-botsvar med Telegram-varningar
Det här n8n-arbetsflödet ligger mellan Bitrix24 och dina bot-åtgärder. Det startar när Bitrix24 skickar en inkommande webhook-händelse till n8n. Innan något annat händer sätter flödet de autentiseringsvariabler det förväntar sig och validerar app-token, så att slumpmässiga förfrågningar inte triggar bot-beteende. Sedan routas händelsen efter typ: vanliga chattmeddelanden går genom ett transformationssteg (så att din svarlogik får felfria, konsekventa fält), anslutningshändelser triggar ett välkomstmeddelande och installationshändelser bygger en registreringspayload och anropar Bitrix24 för att registrera eller uppdatera boten. När något inte är giltigt returnerar det ett fel direkt i stället för att misslyckas i tysthet. Felfritt in. Felfritt ut.
Flödet börjar med en Bitrix24-webhook, sedan token-kontroll och därefter event-routing. Därifrån skickar det antingen ett chattsvar, ett välkomstmeddelande eller registrerar boten via en HTTP-förfrågan. Varje väg slutar med ett tydligt ”success” (eller ”error”) tillbaka till Bitrix24, så att du kan testa och lita på vad som händer.
Det du får: Automatisering vs. resultat
| Det här automatiserar arbetsflödet | Resultat du får |
|---|---|
|
|
Exempel: Så här ser det ut
Säg att ditt team får ungefär 40 Bitrix24-chattmeddelanden per dag, och att ungefär hälften är ”första kontakt”-frågor som kan få en omedelbar bekräftelse. Manuellt blir även 2 minuter per meddelande cirka 40 minuter dagligen, plus avbrott. Med det här arbetsflödet är den enda mänskliga tiden triggern (noll minuter) och enstaka granskning av edge cases; botsvaret och token-kontrollen kör automatiskt på sekunder. Det är ungefär 3 timmar tillbaka varje vecka – och svaren slutar bero på vem som är online.
Det du behöver
- n8n-instans (testa n8n Cloud gratis)
- Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
- Bitrix24 för att skicka chatthändelser via webhooks
- Telegram för valfria interna varningar och notiser
- Bitrix24 app-token (hämta den från dina Bitrix24 app-/webhook-inställningar)
Kunskapsnivå: Medel. Du kopierar webhook-URL:er, sätter credentials och justerar meddelandetext på ett säkert sätt.
Vill du inte sätta upp detta själv? Prata med en automationsspecialist (gratis 15-minuters konsultation).
Så fungerar det
Bitrix24 triggar arbetsflödet. En meddelande-, anslutnings-, installations- eller borttagningshändelse når din n8n webhook-endpoint, som blir den enda ingången för bot-aktivitet.
Token-validering sker direkt. n8n sätter de auth-variabler som behövs och kontrollerar sedan inkommande token så att du inte kör åtgärder för spoofade eller inaktuella förfrågningar.
Händelsetypen routas till rätt beteende. Meddelanden transformeras till felfria fält innan ett svar skickas. Anslutningshändelser skickar ett välkomstmeddelande. Installationshändelser genererar en registreringspayload och anropar Bitrix24 för att registrera boten (eller uppdatera den).
Arbetsflödet returnerar ett tydligt svar. Varje väg slutar med ett ”success”-webhook-svar tillbaka till Bitrix24, eller ett felsvar när autentisering misslyckas, så att du kan felsöka utan gissningar.
Du kan enkelt ändra svarscontent så att det matchar din ton, eller växla Telegram-varningar från ”endast fel” till ”varje installationshändelse” beroende på behov. Se den fullständiga implementeringsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera webhook-triggern
Sätt upp den inkommande endpoint som Bitrix24 kommer att anropa för bot-händelser.
- Lägg till noden Incoming Webhook Intake.
- Ställ in Path på
bitrix24/handler.php. - Ställ in HTTP Method på
POST. - Ställ in Response Mode på
responseNodeför att använda Return Success Reply och Return Error Reply.
Steg 2: anslut autentiseringsvariabler för boten
Mappa inkommande auth-värden och lägg till era applikationsuppgifter för efterföljande API-anrop.
- Lägg till noden Assign Auth Variables och aktivera Include Other Fields.
- Ställ in CLIENT_ID på
[YOUR_ID]och CLIENT_SECRET på[CONFIGURE_YOUR_API_KEY]. - Ställ in application_token på
{{ $json.body['auth[application_token]'] }}. - Ställ in domain på
{{ $json.body['auth[domain]'] }}. - Ställ in access_token på
{{ $json.body['auth[access_token]'] }}.
[YOUR_ID] och [CONFIGURE_YOUR_API_KEY] med era faktiska Bitrix24-appvärden, annars misslyckas tokenverifieringen.Steg 3: validera tokens och routa händelser
Verifiera applikationstoken och styr varje händelse till rätt flöde.
- Konfigurera Verify App Token med ett villkor där Left Value är
{{ $json.CLIENT_ID }}och Right Value är{{ $json.application_token }}. - Behåll det sekundära alltid-sanna villkoret (vänster
1är lika med höger1) om ni vill kunna kringgå kontrollen under test. - Koppla true-utgången från Verify App Token till Event Router och false-utgången till Return Error Reply.
- I Event Router skapar ni regler som kontrollerar
{{ $json.body.event }}förONIMBOTMESSAGEADD,ONIMBOTJOINCHAT,ONAPPINSTALLochONIMBOTDELETE.
Steg 4: sätt upp hantering för meddelanden och installation
Transformera inkommande händelser till rätt payloads för bot-registrering och meddelandesvar.
- I Transform Chat Message behåller ni logiken som läser
data[PARAMS][MESSAGE]och returnerarDIALOG_ID,MESSAGE,AUTHochDOMAIN. - I Handle Join Event säkerställer ni att den returnerar ett välkomstmeddelande med
DIALOG_ID,MESSAGE,AUTHochDOMAIN. - I Prepare Install Payload ställer ni in CODE på
LocalExampleBotoch uppdaterar PROPERTIES.EMAIL från[YOUR_EMAIL]till er riktiga e-postadress. - Bekräfta att Prepare Install Payload använder
handler_back_urlfrånitem.json.webhookUrlså att boten skickar händelser tillbaka till er webhook.
item.json.webhookUrl saknas kommer bot-installationen att misslyckas. Säkerställ att webhook-URL:en finns i den inkommande payloaden eller skicka med den från er installationsprocess.Steg 5: konfigurera utgående API-anrop
Skicka bot-registrering och meddelandesvar till Bitrix24-endpoints.
- I Register Bot Request ställer ni in URL på
=https://{{ $json.DOMAIN }}/rest/imbot.register?auth={{$json.AUTH}}och behåller Method somPOST. - Ställ in body-parametrar i Register Bot Request: EVENT_MESSAGE_ADD, EVENT_WELCOME_MESSAGE och EVENT_BOT_DELETE till
{{$json.handler_back_url}}. - Ställ in PROPERTIES på
{{ { NAME: 'Bot', LAST_NAME: 'Example', COLOR: 'AQUA', EMAIL: '[YOUR_EMAIL]', PERSONAL_BIRTHDAY: '2020-07-18', WORK_POSITION: 'Report on affairs', PERSONAL_GENDER: 'M' } }}och ersätt[YOUR_EMAIL]. - I Dispatch Chat Message ställer ni in URL på
=https://{{$json.DOMAIN}}/rest/imbot.message.add?auth={{$json.AUTH}}och mappar DIALOG_ID, MESSAGE och AUTH till{{ $json.DIALOG_ID }},{{ $json.MESSAGE }}och{{ $json.AUTH }}. - I Dispatch Welcome Message använder ni samma URL och body-mappningar som Dispatch Chat Message.
- Lämna Handle Bot Removal som en noOp tills vidare; den fungerar som en platshållare för framtida städåtgärder.
Steg 6: lägg till felhantering
Returnera ett tydligt fel när applikationstoken är ogiltig.
- Konfigurera Return Error Reply med Respond With inställt på
json. - Ställ in Response Code på
401. - Ställ in Response Body på
{{ "result": false, "error": "Invalid application token" }}. - Säkerställ att false-utgången från Verify App Token är kopplad till Return Error Reply.
Steg 7: testa och aktivera ert workflow
Verifiera varje händelseflöde och aktivera workflowet för produktion.
- Använd test-URL:en i Incoming Webhook Intake för att skicka en exempel-payload med
body.eventsatt tillONIMBOTMESSAGEADDoch bekräfta att Dispatch Chat Message körs. - Skicka en test-payload med
body.eventsatt tillONIMBOTJOINCHAToch bekräfta att Dispatch Welcome Message körs. - Skicka en test-payload med
body.eventsatt tillONAPPINSTALLoch verifiera att Register Bot Request returnerar ett lyckat svar. - Trigga ett misslyckat token-test genom att ändra
application_tokenoch bekräfta att Return Error Reply svarar med401och fel-JSON:en. - När testerna passerar växlar ni workflowet till Active för att börja hantera live-händelser.
Vanliga fallgropar
- Bitrix24-uppgifter kan löpa ut eller sakna rätt behörigheter. Om något går sönder, kontrollera först din Bitrix24 app-token och webhook-/appinställningar.
- Om du använder Wait-noder eller är beroende av externa tjänster under bot-registrering varierar processtiderna. Öka väntetiden om efterföljande noder misslyckas på tomma svar.
- Standardsvar från botar låter ofta generiska. Lägg in er tonalitet tidigt i meddelandetransformationssteget, annars kommer du att skriva om svar hela tiden.
Vanliga frågor
Cirka 30–60 minuter när din Bitrix24-token är klar.
Nej. Du klistrar främst in webhook-detaljer och redigerar några svarsfält. Den enda ”kodliknande” delen är valfri meddelandeformatering, och du kan hålla det enkelt.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med Bitrix24/Telegram-kostnader (oftast minimala om du inte har väldigt hög volym).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och klarar n8n bra. Self-hosting ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det är hela poängen med designen. Du kan ändra svarstexten i meddelandetransformationssteget och sedan byta vilken HTTP Request-nod som körs för olika händelsetyper i routern. Vanliga anpassningar är olika välkomstmeddelanden vid anslutning, att skicka Telegram-varningar endast vid token-fel och att lägga till ett ”lämna över till människa”-nyckelord som stoppar automatiska svar.
För det mesta beror det på en felaktig eller utgången app-token, så generera en ny i Bitrix24 och uppdatera värdet i n8n. Kontrollera också att webhooken pekar på rätt n8n-URL (produktion vs. test). Om installationer plötsligt slutar registreras, bekräfta att Bitrix24-kontot har behörighet att registrera botar och att installationshändelsen fortfarande skickas.
Ett typiskt litet team kan köra hundratals händelser per dag utan problem om HTTP-endpoints svarar snabbt.
Ofta, ja, eftersom det här inte bara är ”skicka ett meddelande när X händer”. Du har token-validering, event-routing och olika beteenden för installation vs. meddelande vs. anslutning – vilket är där n8n glänser. Self-hosting spelar också roll här: om du hanterar många chatthändelser blir prissättning per task snabbt irriterande. Zapier eller Make kan fortfarande vara bra för en minimal setup, särskilt om du bara behöver en händelsetyp och en åtgärd. Om du vill ha en second opinion om avvägningarna utifrån din volym och dina säkerhetskrav, prata med en automationsspecialist.
När detta väl är igång slutar din Bitrix24-chatt vara ett konstant avbrott. Arbetsflödet tar hand om de repetitiva svaren och säkerhetskontrollerna, så att teamet kan fokusera på samtal som faktiskt driver saker framåt.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.