Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
januari 22, 2026

ConnectWise till Teams: rensade ticket-varningar

Rickard Andersson Partner, Nodenordic.se

Din dispatch-kanal ska inte kännas som en enarmad bandit. Ena minuten är det tyst, nästa är det en hög ConnectWise-biljetter i status ”New”, inklusive dubbletter, och ändå missar någon den som faktiskt är viktig.

Det här slår hårdast mot dispatch-ansvariga, ärligt talat. Men även service managers och ops-ägare känner av det, eftersom Teams-biljettaviseringar blir stökiga, inkonsekventa och lätta att ignorera. Det här arbetsflödet gör om det till strukturerade, grupperade uppdateringar som folk faktiskt läser.

Du får se hur automatiseringen hämtar nya biljetter från ConnectWise Manage, avdubbletter dem med en cache, grupperar dem per företag och postar en enda Teams-notis till dispatch enligt schema.

Så fungerar automatiseringen

Se hur detta löser problemet:

n8n Workflow Template: ConnectWise till Teams: rensade ticket-varningar

Utmaningen: Teams-brus som döljer ”New”-biljetter

De flesta dispatch-team har inte problem för att de ”saknar ett ärendehanteringssystem”. De har problem för att i samma ögonblick en biljett blir ”New” måste den konkurrera med allt annat: chattrådar, @omnämnanden, möten och det ständiga flödet. Om du manuellt kollar ConnectWise Manage tappar du både tid och fokus. Om du postar ett meddelande per biljett blir kanalen snabbt spamig. Då tystar folk den, och sen är ni tillbaka i missade överlämningar, dubbelt arbete och ”jag trodde någon tog den”-snack.

Det eskalerar snabbt. Här är var det faller isär i verkligheten.

  • Dispatch slutar med att kolla ConnectWise om och om igen ”för säkerhets skull”, vilket bränner cirka 30 minuter per dag i små avbrott.
  • Dubblettaviseringar dyker upp efter varje körning, så kanalen ser aktiv ut trots att inget nytt faktiskt händer.
  • Biljetter kommer i en platt lista, vilket gör det svårt att se mönster som ”tre nya problem från samma kund”.
  • När aviseringsflödet känns opålitligt slutar folk lita på det och går tillbaka till manuell kontroll.

Lösningen: avdubbletterade, grupperade ConnectWise-biljetter i Teams

Det här arbetsflödet körs enligt schema och frågar ConnectWise Manage, via en säker HTTPS-förfrågan, ”Vilka biljetter har just nu status New?” Sedan jämför det resultatet mot en enkel cache som lagras i Redis, så att biljetter du redan har blivit notifierad om inte postas igen. Efter filtrering grupperar det kvarvarande biljetter per företag, så att dispatch ser en sammanfattning kund för kund i stället för ett brusigt flöde. Till sist postar det en dispatch-notis i Microsoft Teams som är lätt att skumma, agera på och hänvisa till senare. Slutresultatet är färre pingar, färre upprepningar och större chans att rätt biljett snabbt blir tilldelad.

Arbetsflödet startar med den schemalagda triggern och hämtar sedan ”New”-biljetter från ConnectWise. Redis fungerar som arbetsflödets minne, så det vet vad det redan har skickat. Efter att biljetterna har grupperats per företag får Teams en enda strukturerad uppdatering i stället för ett dussin spridda inlägg.

Vad som förändras: före vs. efter

Praktisk effekt i vardagen

Säg att du kör detta var 10:e minut under kontorstid (cirka 50 kontroller per dag). Utan automatisering kanske en dispatcher öppnar ConnectWise ”bara för att titta” i ungefär en minut varje gång, plus några längre kontroller, vilket landar runt en timme per dag. Med det här arbetsflödet kör triggern automatiskt, hämtningen från ConnectWise och filtreringen sker i bakgrunden, och Teams får en grupperad notis bara när något är nytt. Du agerar fortfarande på biljetter, men du slutar lägga tid på att leta efter dem.

Krav

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • ConnectWise Manage för att hämta biljetter via REST API.
  • Microsoft Teams för att posta dispatch-notiser till en kanal.
  • Redis för att lagra en cache över ”skickade biljetter”.
  • ConnectWise API-inloggningsuppgifter (hämta dem från din ConnectWise Manage Member/API-konfiguration).

Svårighetsgrad: Medel. Du kopplar konton, lägger in inloggningsuppgifter säkert och bekräftar val för ConnectWise-status och Teams-kanal.

Behöver du hjälp att implementera detta? Prata med en automationsspecialist (gratis 15-minuters konsultation).

Flödet i arbetsflödet

En schemalagd kontroll körs automatiskt. Du bestämmer takten (varje par minuter, var 15:e minut, vad som än matchar din dispatch-rytm). Den är konsekvent, så det blir inget ”någon glömde att kolla”.

ConnectWise-biljetter hämtas via REST. n8n använder en HTTP-förfrågan för att hämta biljetter i status ”New” (eller en annan status om du ändrar den). Det enda filtret är skillnaden mellan en ”åtgärdsbar kö” och ett ”oändligt flöde”.

Arbetsflödet kommer ihåg vad det redan har skickat. Redis lagrar biljettidentifierare, och arbetsflödet slår ihop senaste hämtningen med cachen så att tidigare aviserade biljetter inte postas igen. Det här är delen som håller dina Teams-biljettaviseringar strukturerade i stället för repetitiva.

Biljetterna grupperas och postas sedan till Teams. Efter filtrering grupperar arbetsflödet biljetter per företag och publicerar en dispatch-notis i Microsoft Teams som är gjord för att kunna skummas snabbt.

Du kan enkelt justera statusfiltret för biljetter så att det matchar din triageprocess utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: konfigurera den schemalagda triggern

Ställ in arbetsflödet så att det körs automatiskt enligt ett definierat schema med triggernoden.

  1. Lägg till noden Scheduled Automation Trigger som arbetsflödets trigger.
  2. Ställ in Rule till ett cron-uttryck med */1 8-16 * * 1-5 för att köra varje minut under kontorstid på vardagar.
  3. Koppla Scheduled Automation Trigger till Fetch New Tickets.

Steg 2: anslut ärendekällan och cache-uppslag

Hämta nya ärenden från ConnectWise och kontrollera Redis för att undvika att skicka aviseringar igen.

  1. Konfigurera Fetch New Tickets med URL satt till https://na.myconnectwise.net/v4_6_release/apis/3.0/service/tickets?conditions=(status/name="New" or status/name="New (email)" or status/name="New (portal)") and (board/id=25 or board/id=26 or board/id=1 or board/id=28) and parentTicketId=null&PageSize=999.
  2. Aktivera Send Headers och lägg till Header Parameters med Name clientId och Value [YOUR_ID].
  3. Inloggningsuppgifter krävs: anslut era httpHeaderAuth-uppgifter i Fetch New Tickets.
  4. Konfigurera Retrieve Cache Entry med Operation get, Key Type string, Key ={{ $json.id.toString() }} och Property Name =Tickets.
  5. Inloggningsuppgifter krävs: anslut era redis-uppgifter i Retrieve Cache Entry.

Fetch New Tickets skickar utdata parallellt till både Retrieve Cache Entry och Append Filter Key.

Om ert ConnectWise-API returnerar fler än 999 poster, överväg pagineringslogik för att undvika att missa ärenden.

Steg 3: konfigurera filtrering och gruppering av ärenden

Förbered ärende-ID:n för jämförelse, exkludera tidigare skickade poster och gruppera ärenden per företag.

  1. I Append Filter Key, behåll den angivna JavaScript Code för att typkonvertera id till en sträng och sätta FilterOnThis för merge-jämförelser.
  2. Konfigurera Exclude Previously Sent Tickets med Mode combine, Join Mode keepNonMatches och Output Data From input1.
  3. Ställ in Merge By Fields för att jämföra Field 1 FilterOnThis med Field 2 Tickets, och låt Fuzzy Compare vara aktiverat.
  4. I Group Tickets by Company, behåll den angivna JavaScript Code för att gruppera objekt efter siteName och company och bygga HTML-listan tickets.

Exclude Previously Sent Tickets skickar utdata parallellt till både Group Tickets by Company och Write Ticket to Cache.

⚠️ Vanlig fallgrop: säkerställ att inkommande ärende-JSON innehåller fälten siteName, company, recordType och summary; annars kommer Group Tickets by Company inte att formatera meddelanden korrekt.

Steg 4: konfigurera cache-skrivningar och Teams-notifieringar

Lagra nya ärende-ID:n i Redis och skicka grupperade aviseringar till Microsoft Teams.

  1. Konfigurera Write Ticket to Cache med Operation set, Key ={{ $json.id }} och Value ={{ $json.id }}.
  2. Inloggningsuppgifter krävs: anslut era redis-uppgifter i Write Ticket to Cache.
  3. Konfigurera Post Teams Dispatch Notice med Chat ID satt till [YOUR_ID].
  4. Ställ in Message Type till html och Message till =Hey Dispatch Team!, A new {{ $json.ticketType }} has come in.

    Ticket: {{ $json.tickets }} Company: {{ $json.companyName.name }}
    .
  5. Inloggningsuppgifter krävs: anslut era microsoftTeamsOAuth2Api-uppgifter i Post Teams Dispatch Notice.

Steg 5: testa och aktivera ert arbetsflöde

Verifiera att hela flödet körs, filtrerar korrekt och publicerar aviseringar till Teams.

  1. Klicka på Execute Workflow för att köra arbetsflödet manuellt och bekräfta att Fetch New Tickets returnerar ärendedata.
  2. Verifiera att Exclude Previously Sent Tickets bara skickar ut nya ärenden och att Write Ticket to Cache sätter ID:n i Redis.
  3. Bekräfta att Post Teams Dispatch Notice publicerar ett grupperat HTML-meddelande i den valda Teams-chatten.
  4. När ni är nöjda, växla arbetsflödet till Active så att Scheduled Automation Trigger kör det enligt schemat.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Saker att se upp med

  • ConnectWise Manage-inloggningsuppgifter kan löpa ut eller kräva specifika behörigheter. Om något skapar fel, kontrollera först dina ConnectWise Member/API-behörigheter och REST-endpointens svar i HTTP Request-noden.
  • Redis-cachning hjälper bara om strategin för cache-nycklar är stabil. Om du ändrar hur ”filter key” byggs kan du råka avisera gamla biljetter igen tills cachen har byggts upp på nytt.
  • Inlägg i Microsoft Teams kan misslyckas utan tydliga fel om kanal- eller webhook/app-behörigheter ändras. Om aviseringar slutar komma, verifiera Teams-anslutningen i n8n och bekräfta att målkanalen fortfarande finns.

Vanliga frågor

Hur snabbt kan jag implementera den här automatiseringen för Teams-biljettaviseringar?

Oftast på ungefär en timme när din ConnectWise API-åtkomst är klar.

Kan icke-tekniska team implementera den här automatiseringen för biljettaviseringar?

Ja. Ingen kodning krävs, men någon behöver vara bekväm med att lägga in inloggningsuppgifter och testköra ett flöde från start till mål.

Är n8n gratis att använda för det här arbetsflödet för Teams-biljettaviseringar?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna in hosting för Redis och eventuella ConnectWise API-begränsningar som din plan har.

Var kan jag hosta n8n för att köra den här automatiseringen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.

Hur anpassar jag den här lösningen för Teams-biljettaviseringar till mina specifika utmaningar?

Du kan ändra statusfiltret i ConnectWise i HTTP Request ”Fetch New Tickets” för att bevaka ”New”, ”Pending Dispatch” eller valfri status som matchar din process. Många team justerar också logiken i ”Group Tickets by Company” för att sortera på prioritet eller board, så att Teams-meddelandet läses som en triagelista. Om din dispatch vill ha färre pingar, öka schemaintervallet och behåll grupperingen. Om du vill ha nära realtid, kör oftare och skärp Redis-nyckeln för avdubblettering så att upprepningar hålls borta.

Varför fallerar min ConnectWise Manage-anslutning i det här arbetsflödet?

Oftast beror det på utgångna inloggningsuppgifter eller saknade API-behörigheter på den ConnectWise-medlem du använder. Kontrollera senaste svaret i HTTP Request-noden i n8n, och bekräfta sedan att endpoint, company/site-värde och autentiseringsmetod matchar din ConnectWise REST-konfiguration. Om det fungerar i ett verktyg som Postman men misslyckas i n8n är det oftast headers eller en mismatch i miljövariabler. Det är också värt att kontrollera rate limits om du hämtar stora boards ofta.

Vilken kapacitet har den här lösningen för Teams-biljettaviseringar?

I självhostad n8n finns inget hårt tak för antal körningar; det beror främst på din server och ConnectWise API-begränsningar. I n8n Cloud beror din månatliga körningskvot på planen, och det här arbetsflödet räknas som cirka en körning per schemalagd körning. I praktiken kör de flesta team det var 5–15:e minut under kontorstid utan problem. Om du behöver högre frekvens, behåll meddelandegrupperingen och se till att Redis är stabilt, eftersom det är det som förhindrar aviseringsspam.

Är den här automatiseringen för Teams-biljettaviseringar bättre än att använda Zapier eller Make?

Ofta, ja. Avdubblettering med Redis och grupperingslogiken är mycket enklare att uttrycka i n8n utan att betala extra för grenar, kodsteg eller ”premium”-funktioner, och du kan köra egen drift om du vill ha obegränsade körningar. Zapier eller Make kan fortfarande fungera om behoven är enkla, som ”posta varje ny biljett som ett meddelande”, men det är också så kanaler blir stökiga. Det här arbetsflödet är byggt specifikt för att hålla Teams läsbart, vilket är hela poängen. Om du är osäker, prata med en automationsspecialist så mappar vi det mot din dispatch-process.

Strukturerade aviseringar förändrar beteenden. När dispatch litar på det som dyker upp i Teams slutar du jaga ”nytt” arbete och börjar driva det 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.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!

Få prisoffert redan idag!
Få prisoffert redan idag!

Berätta vad ni behöver hjälp med så hör vi av oss inom en arbetsdag!

Launch login modal Launch register modal