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

GitHub + Slack: tilldela ärenden med ”assign me”

Rickard Andersson Partner, Nodenordic.se

Du tappar inte tid i stora sjok med GitHub-issues. Du tappar den i små. Läsa kommentarer, kolla om en issue redan är tagen, tilldela personer manuellt och sedan reda ut “vänta, jag trodde jag hade den”-förvirringen.

Det här drabbar open source-maintainers först, om vi ska vara ärliga. Men tekniska leads och byråteam som levererar snabbt känner samma smärta. Med den här automatiseringen för GitHub Slack assignment blir issues “claimade” i samma sekund som någon skriver “assign me”, och teamet hålls uppdaterat utan att någon behöver göra en manuell triage-runda.

Nedan ser du hur arbetsflödet beter sig, vad det förändrar i vardagen och grunderna för att sätta upp det så att du kan köra det tryggt.

Så fungerar den här automatiseringen

Hela n8n-arbetsflödet, från trigger till slutresultat:

n8n Workflow Template: GitHub + Slack: tilldela ärenden med ”assign me”

Problemet: “assign me” ska inte kräva en maintainer

I repo:n med mycket aktivitet blir tilldelning av issues en märklig flaskhals. En contributor kommenterar “assign me” och väntar. En maintainer måste se kommentaren, kontrollera att issue:n fortfarande är ledig, tilldela personen och ibland förklara att någon annan redan tog den. Under tiden kan två personer börja med samma arbete, eller så börjar ingen eftersom alla väntar på bekräftelse. Det är inte svårt. Det är bara konstant, och det stjäl fokus från granskningar, roadmap-beslut och leverans.

Friktionen bygger på. Här är var det fallerar.

  • Folk “claimar” issues i kommentarer, men tilldelningen sker inte förrän någon med rättigheter är online.
  • Två contributors kan “paxa” samma timme, och du får medla i en konflikt som automatisering hade kunnat förhindra.
  • Maintainers och team leads bränner cirka 1–2 timmar i veckan på repetitiva triage-steg i aktiva projekt.
  • Utan en konsekvent “assigned”-signal blir backlog-vyn rörig och planeringsmöten tar längre tid än de borde.

Lösningen: auto-tilldela issues när någon kommenterar “assign me”

Det här n8n-arbetsflödet lyssnar på GitHub-aktivitet och reagerar som en bra maintainer skulle göra, varje gång. När en ny issue kommer in (eller en ny kommentar landar på en befintlig) kontrollerar flödet vad som hände och skickar händelsen vidare längs rätt väg. Om någon försöker claima arbete genom att skriva “assign me” verifierar det att issue:n faktiskt är otilldelad, tilldelar rätt person och håller repo-statusen strukturerad. Om issue:n redan är tagen postar det en artig notis så att contributors får besked direkt och inte slösar tid. Slutresultatet är ett self-service-system för att claima arbete som fortfarande följer “först till kvarn”.

Arbetsflödet startar med en GitHub-trigger. Sedan avgör det om händelsen är en ny issue eller en kommentar, bekräftar att begäran är giltig och utför rätt tilldelningsåtgärd. Till sist lämnar det repo:t i ett tydligare läge (och kan paras ihop med Slack-notiser för bättre synlighet).

Det här får du: automatisering vs. resultat

Exempel: så här ser det ut

Säg att ditt repo får runt 30 “assign me”-kommentarer i veckan. Manuellt tar även en snabb kontroll-och-tilldela kanske 2 minuter varje gång (öppna issue:n, bekräfta att den är ledig, tilldela, svara), alltså cirka 1 timme per vecka, plus enstaka konflikter som lägger till ytterligare 30 minuter. Med det här flödet är den mänskliga tiden nära noll efter uppsättning: triggern går direkt, kontrollerna körs på sekunder och ansvarig sätts utan att någon behöver bevaka GitHub hela dagen.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • GitHub för issue-händelser och tilldelningar
  • Slack för att notifiera teamet (valfri koppling)
  • GitHub OAuth-uppgifter (skapa i GitHub Developer settings)

Kunskapsnivå: Nybörjare. Du kopplar GitHub, väljer ditt repo och bekräftar tilldelningsbeteendet.

Vill du inte sätta upp detta själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).

Så fungerar det

GitHub-aktivitet triggar arbetsflödet. När en ny issue skapas eller en kommentar läggs till tar n8n emot händelsen via noden GitHub Trigger.

Arbetsflödet routar händelsetypen. En switch kontrollerar åtgärden (ny issue vs. kommentar) så att automatiseringen inte behandlar allt på samma sätt.

Tilldelningen valideras innan något ändras. För nya issues verifierar det att issue:n just nu är otilldelad innan den tilldelar. För kommentarer kontrollerar det att kommentaren innehåller “assign me” och bekräftar sedan att issue:n fortfarande är ledig.

Resultatet tillämpas i GitHub. Om issue:n är ledig tilldelas kommenteraren (eller issue-skaparen, beroende på väg) automatiskt. Om den redan är tilldelad postar arbetsflödet en notis så att contributorn får ett tydligt svar direkt i tråden.

Du kan enkelt ändra frasmatchningen (“assign me”) så att den passar er repo-kultur, eller ändra vart notiser ska skickas (Slack, Teams, e-post) utifrån behov. Se hela implementationsguiden nedan för anpassningsalternativ.

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

Steg 1: Konfigurera webhook-triggern

Konfigurera GitHub-webhook-triggern så att arbetsflödet kan svara på händelser för issues och kommentarer.

  1. Lägg till noden GitHub Event Trigger och ställ in AuthenticationoAuth2.
  2. Ställ in Owner på repository-ägaren (mallen använder [username]).
  3. Ställ in Repository på ert repo (mallen använder [reponame]).
  4. Välj Events som issue_comment och issues.
  5. Autentiseringsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter.

Tips: Säkerställ att er GitHub OAuth-app har repo-åtkomst, annars kommer triggern inte att ta emot händelser.

Steg 2: Anslut GitHub

Konfigurera GitHub-uppgifter för alla åtgärdsnoder som redigerar issues eller publicerar kommentarer.

  1. Öppna Assign Issue Author och bekräfta att Authentication är satt till oAuth2.
  2. Autentiseringsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter till Assign Issue Author.
  3. Öppna Assign Comment Author och bekräfta att Authentication är satt till oAuth2.
  4. Autentiseringsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter till Assign Comment Author.
  5. Öppna Post Existing Assignee Note och bekräfta att Authentication är satt till oAuth2.
  6. Autentiseringsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter till Post Existing Assignee Note.

Steg 3: Sätt upp routning för åtgärder

Routa inkommande GitHub-händelser efter åtgärdstyp och validera om tilldelning ska ske.

  1. I Route by Action ställer ni in Value 1 till ={{$json["body"]["action"]}}.
  2. Lägg till regler i Route by Action för Value 2 som opened (issues) och created (kommentarer).
  3. I Validate Unassigned Issue ställer ni in siffervillkoret till ={{$json["body"]["issue"]["assignees"].length}} med Operation equal.
  4. I Validate Unassigned Issue lägger ni till ett villkor för sträng-regex med Value 1 ={{$json["body"]["issue"]["body"]}} och Value 2 /[a,A]ssign[\w*\s*]*me/gm.
  5. I Check Comment Request lägger ni till ett villkor för sträng-regex med Value 1 ={{$json["body"]["comment"]["body"]}} och Value 2 /[a,A]ssign[\w*\s*]*me/gm.
  6. I Confirm Issue Free ställer ni in siffervillkoret till ={{$json["body"]["issue"]["assignees"].length}} med Operation equal.

⚠️ Vanlig fallgrop: Regexen är skiftlägeskänslig förutom den hakparentesade [a,A]. Om ert team använder annan formulering, uppdatera mönstret i både Validate Unassigned Issue och Check Comment Request.

Steg 4: Konfigurera åtgärder för tilldelning

Definiera hur arbetsflödet tilldelar issues och publicerar återkoppling när en issue redan är tilldelad.

  1. I Assign Issue Author ställer ni in Owner till ={{$node["Route by Action"].json["body"]["repository"]["owner"]["login"]}}.
  2. Ställ in Repository till ={{$node["Route by Action"].json["body"]["repository"]["name"]}} och Issue Number till ={{ $json["body"]["issue"]["number"] }}.
  3. I Assign Issue Author under Edit Fields ställer ni in Assignees till ={{$json.body.issue["user"]["login"]}} och lägger till etiketten assigned.
  4. I Assign Comment Author ställer ni in Owner till ={{$json["body"]["repository"]["owner"]["login"]}} och Repository till ={{$json["body"]["repository"]["name"]}}.
  5. Ställ in Issue Number till ={{$json["body"]["issue"]["number"]}} och ställ in Assignees till ={{$json["body"]["comment"]["user"]["login"]}} med etiketten assigned.
  6. I Post Existing Assignee Note ställer ni in Body till =Hey @{{$json["body"]["comment"]["user"]["login"]}},  This issue is already assigned to {{$json["body"]["issue"]["assignee"]["login"]}} 🙂.
  7. Behåll No Action Placeholder och No Action Placeholder 2 som no-op-grenar för händelser som inte matchar.

Tips: Etiketten assigned måste finnas i ert GitHub-repo, annars skapar GitHub den direkt beroende på era behörigheter.

Steg 5: Testa och aktivera ert arbetsflöde

Verifiera webhooken och tilldelningslogiken innan ni aktiverar arbetsflödet.

  1. Klicka på Execute Workflow för att börja lyssna på händelser från GitHub Event Trigger.
  2. Testa en issue-händelse genom att skapa en ny issue som innehåller ”assign me” i brödtexten; bekräfta att Assign Issue Author körs och att issuen etiketteras och tilldelas.
  3. Testa en kommentars-händelse genom att kommentera ”assign me” på en o-tilldelad issue; bekräfta att Assign Comment Author körs.
  4. Testa en kommentar på en issue som redan är tilldelad; bekräfta att Post Existing Assignee Note publicerar meddelandet.
  5. När allt fungerar, slå på arbetsflödet till Active för produktionsbruk.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • GitHub-credentials kan gå ut eller kräva specifika behörigheter. Om något slutar fungera, kontrollera först dina GitHub-credentials i n8n och repo:ts åtkomstinställningar.
  • Om du använder Wait-noder eller extern rendering varierar processingtider. Öka väntetiden om nedströmsnoder misslyckas på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in er tonalitet tidigt, annars kommer du att redigera output för alltid.

Vanliga frågor

Hur lång tid tar det att sätta upp den här automatiseringen för GitHub Slack assignment?

Cirka 5 minuter om dina GitHub-credentials är klara.

Behöver jag kunna koda för att automatisera tilldelning av GitHub-issues?

Nej. Du kopplar mest GitHub och bekräftar ett par villkor. Kan du följa en checklista kan du köra det.

Är n8n gratis att använda för det här arbetsflödet för GitHub Slack assignment?

Ja. n8n har ett gratis self-hosted-alternativ och en gratis testperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in GitHub-åtkomst (oftast gratis) och eventuella valfria notifieringsverktyg du lägger till.

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 self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och klarar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här arbetsflödet för GitHub Slack assignment till ett annat nyckelord än “assign me”?

Ja, och det är en vanlig justering. Uppdatera villkoret som kontrollerar kommentaren i flödesvägen “Check Comment Request” så att det matchar den fras du föredrar (som “/claim” eller “take this”), och behåll sedan kontrollen “Confirm Issue Free” som den är så att du inte introducerar konflikter. Många team lägger också till en andra regel för maintainers, så att “assign @name” fungerar också. Resten av arbetsflödet behöver inte ändras.

Varför misslyckas min GitHub-anslutning i det här arbetsflödet?

Oftast beror det på utgångna OAuth-credentials eller saknade repo-behörigheter. Anslut dina GitHub-credentials igen i n8n och bekräfta sedan att token har åtkomst till organisationen och repo:t där issues finns. Om det bara misslyckas på vissa repo:n, kontrollera om SSO är tvingande för din org och att token inte auktoriserats. Håll också koll på GitHub rate limits om du hanterar många händelser under peak-timmar.

Hur många issues kan den här automatiseringen för GitHub Slack assignment hantera?

En typisk uppsättning kan hantera hundratals tilldelningshändelser per dag.

Är den här automatiseringen för GitHub Slack assignment bättre än att använda Zapier eller Make?

Ofta, ja, eftersom det här arbetsflödet bygger på förgrenad logik (issue vs. kommentar, “assign me” finns, redan tilldelad eller inte) och GitHub-specifika åtgärder som kan bli klumpiga i enklare verktyg. n8n ger dig också self-hosting-alternativet, vilket spelar roll när ditt repo är stökigt och du inte vill behöva räkna varje körning. Zapier eller Make kan fortfarande vara helt okej om du bara gör ett enkelt tvåstegsflöde och accepterar färre skyddsmekanismer. Om du vill ha Slack-notiser, godkännandesteg eller fler villkor senare brukar n8n hålla bättre över tid. Prata med en automatiseringsexpert om du är osäker på vad som passar.

Tilldelning av issues är inte där din uppmärksamhet ska ligga. Sätt upp det här en gång, låt contributors hantera det själva och håll backloggen strukturerad utan att behöva passa den.

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