Lektion 2 · fortsättning

Från modell till felsökning och mini-labb

I lektion 1 byggde vi den mentala modellen. Nu tittar vi på runtime: hur ni läser ett flöde, tolkar fel, hittar rätt steg och avgör om problemet sitter i payload, konfiguration eller leverantör.

HTTP-statuskoder n8n executions Miljövariabler Flowise Twenty Mini-labb

Målet idag: ni ska kunna säga var ett flöde stannar och hur ni bevisar det steg för steg.

Det vi tar med oss från lektion 1

Systemgränsen är satt.
Varje tjänst har ett tydligt ansvar.
Flödet är: signal in → n8n → AI / CRM / supportyta → organisationen.

Utgångspunkt

Det här vet vi redan, och det är därför felsökningen blir begriplig

Från lektion 1

Vi byggde inte ett "allt-i-ett"-verktyg.
Vi valde separata lager för insamling, orkestrering, AI och affärsdata.
Vi vet vilken tjänst som borde göra vad.

Varför det hjälper nu

Om "24 Zombie Guppy Deluxe" kommer in fel börjar vi vid formulär/webhook.
Om AI:n klassar fel produkt eller fel case tittar vi på Flowise.
Om affären inte dyker upp i Twenty tittar vi på CRM-anropet.

Felsökning blir svårt först när ansvaren är otydliga. Därför kom modelleringen innan labben, och därför följer vi samma Bosses-case även här.

Tänk som en kontraktsläsare

Läs flödet som ett kontrakt: input, bearbetning, output

Input

Vad kom in?

Formulärfält som namn, e-post och meddelandet "Vi vill köpa 18 Zombie Guppy Deluxe".

Bearbetning

Vad hände i mitten?

n8n-routning, HTTP mot Flowise, JSON-kategorisering och eventuell omväg till supportspåret.

Output

Vad skulle ut?

CRM-post i Twenty, supportsvar i Chatwoot eller ett webhook-svar med kategori och rekommendation.

Den vanligaste missen är att man tittar för sent i kedjan. Börja alltid där datan först blev fel eller försvann, inte där någon råkade upptäcka problemet.

HTTP i praktiken

Vanliga statuskoder i integrationsflöden

Kod	Vad det brukar betyda	Var du börjar titta
200 / 201	Begäran godtogs. 201 betyder ofta att något skapades.	Nästa steg i kedjan.
400	Payload eller format stämmer inte med API-kontraktet.	Body, fält och datatyper. Exempel: Bosses-leadet saknar e-post eller har fel struktur.
401 / 403	Nyckel saknas, är fel eller saknar rättigheter.	Miljövariabler, token, roller. Exempel: Twenty nekar affären för Zombie Guppy Deluxe.
404	Fel endpoint, fel URL eller fel miljö.	Base URL och endpoint-stig. Exempel: n8n pekar på fel Flowise-chatflow eller fel bas-URL.
429	För många anrop på för kort tid.	Volym, batchning, retry-logik.
500–503	Leverantör eller tjänst har interna problem.	Loggar, status-sidor och om er payload ändå triggar felet.

n8n som felsökningsyta

n8n Executions: den mest konkreta bilden av vad som hänt

Börja här

Öppna senaste execution.
Titta först på webhook-noden: kom rätt data in?
Jämför sedan output mellan noderna steg för steg.

Vanliga frågor att ställa

Är Bosses-leadet normaliserat som vi tänkt?
Returnerade Flowise rätt kategori, till exempel bulk_order eller resurrection_support?
Returnerade Twenty ett person-id eller ett felmeddelande?

Jämför gärna med Zapier-historik: samma tanke, men n8n gör det lättare att se exakt input och output per steg.

Konfiguration · hemligheter

Miljövariabler: där rätt flöde ofta går sönder av fel skäl

`FLOWISE_LEAD_CHATFLOW_ID`

Lead-chatflowet för Bosses. Fel värde gör att bulkorder eller partnercase klassificeras konstigt.

`TWENTY_API_KEY`

Bearer-token för CRM-anrop. Fel värde ger ofta 401 eller 403.

`FLOWISE_SUPPORT_CHATFLOW_ID`

Support-chatflowet för Bosses. Ska ge annan ton och annan kategorisering än leadspåret.

`FLOWISE_CHATWOOT_CHATFLOW_ID`

Valfritt separat chatflow för Chatwoot. Bra när chattstilen ska skilja sig från formulärsupport.

`TWENTY_API_BASE`

Vilken bas-URL n8n använder. Fel adress ger ofta 404 eller timeout.

`OPENAI_API_KEY`

Ligger hos Flowise. Utan den kan Bosses-flödet fungera tekniskt men ge tomma eller misslyckade AI-svar.

En klassisk miss är att anta att "AI:t är trasigt" när Bosses-kategoriseringen egentligen fallerar för att ett chatflow-id, en token eller en omstart glömts bort.

Tre sätt in i samma arkitektur

Lead, supportformulär och Chatwoot följer samma grundmönster

Lead

/webhook/lead tar emot till exempel "Vi vill beställa 24 Zombie Guppy Deluxe" och skriver vidare till CRM.

Supportformulär

/webhook/support tar frågan "Varför rör sig inte min fisk?" och returnerar svar, kategori och eskaleringssignal.

Chatwoot

Webhooks från supportytan går samma väg via n8n och kan ge Bosses-relaterade AI-svar tillbaka i chatten.

Signal in -> n8n -> Flowise -> rätt yta ut

skillnaden ligger mest i om Bosses-caset ska till CRM, support eller eskalering

AI-steg med gränser

Flowise ska bära AI-logiken, inte hela systemlogiken

Det vi vill ha från Flowise

Klassificering, svarsförslag, enklare berikning.
Tydlig promptyta som går att byta eller förbättra.
Ett steg som kan testas separat från resten.
I Bosses-caset: kategorier som bulk_order, addon_question och resurrection_support.

Det vi inte vill göra

Lägga hela affärslogiken i prompten.
Låta AI avgöra allt utan kontrollpunkter.
Göra n8n-flödet beroende av att modellen "gissar rätt".

Samma princip som i lektion 1: AI är ett lager, inte hela lösningen. Bosses blir begripligt först när kategorierna kan läsas och granskas utanför modellen.

CRM · API-kontrakt

Twenty REST: förvänta dig iteration, inte magi

När något inte går igenom till Twenty är det sällan "mystik". Ofta är det payloaden, fältmappningen eller versionen som skiljer sig från det exempel du först tittade på.

Arbeta så här

Läs svarstexten från API:t.
Öppna playground eller dokumentation.
Jämför vad du skickar med vad API:t förväntar sig.

Målet i kursen

Skapa person eller kontakt.
Koppla affär eller nästa steg till rätt objekt.
Skapa en affär i stil med Bosses: bulk_order / Zombie Guppy Deluxe.
Förstå varför CRM är den affärsmässiga slutpunkten för leads.

Gemensam körning

Mini-labb: bevisa var felet sitter

A. Följ en körning

Skicka ett Bosses-lead om 12 Zombie Guppy Deluxe och följ execution i n8n hela vägen till Twenty.

B. Framkalla ett fel

Sätt fel API-nyckel eller fel chatflow-id och avgör om Bosses-felet sitter i auth eller AI-steg.

C. Testa utan frontend

Visa att webhooks bara är HTTP genom att skicka ett Bosses-case med curl.

curl -sS -u admin:admin -X POST http://localhost:5678/webhook/lead \
  -H "Content-Type: application/json" \
  -d '{"name":"Bosse Bubbla","email":"bosse@hotellakvarium.se","message":"Hej! Vi vill beställa 12 Zombie Guppy Deluxe till receptionen och undrar om Återupplivning Plus kan erbjudas som tillägg."}'

Hela poängen med labben är inte att "allt fungerar", utan att ni tränar på att läsa systemet systematiskt.

Sammanfattning

Efter båda lektionerna ska ni kunna förklara kedjan med självförtroende

Beskriva varför vi modellerar innan vi bygger.
Förklara vilken tjänst som äger vilken del av lösningen.
Läsa ett integrationsfel som payload, auth, endpoint eller leverantörsproblem.
Resonera om när AI tillför värde och när den bara skapar mer brus.

Bra automation handlar inte bara om att koppla ihop system. Den handlar om att göra ansvar, dataflöden och beslut begripliga även när caset är lika dumt som Bosses dödfiskbutik.