Godkännandeflaskhalsar är sällan “svåra”. De är bara röriga. Någon pingar en chef, chefen svarar senare, ärendet uppdateras på fel ställe (eller inte alls), och plötsligt letar du igenom chattar för att bevisa vad som faktiskt hände.
Den här automatiseringen för Telegram + Postgres-godkännanden träffar driftchefer först, men IT-ansvariga och kundansvariga på byrå känner av den också. Du får ett strukturerat godkänn/avslå-flöde som uppdaterar ärendet direkt och lämnar ett revisionsspår du faktiskt kan lita på.
Nedan ser du hur flödet routar varje beslut, låser det med signerade länkar, uppdaterar Postgres och notifierar rätt personer utan extra följdfrågor.
Så fungerar automatiseringen
Se hur den löser problemet:
n8n Workflow Template: Telegram + Postgres: ärendegodkännanden med auditloggar
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/>Approval Webhook Intake"]
n1["<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/code.svg' width='40' height='40' /></div><br/>Validate Signature Window"]
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Route Decision Action", pos: "b", h: 48 }
n3["<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/postgres.svg' width='40' height='40' /></div><br/>Modify Ticket Status"]
n4["<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/postgres.svg' width='40' height='40' /></div><br/>Insert Status Audit"]
n5["<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/postgres.svg' width='40' height='40' /></div><br/>Fetch Ticket Owner"]
n6@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Branch Status Check", pos: "b", h: 48 }
n7@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check Resolved State", pos: "b", h: 48 }
n8@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Check In-Progress State", pos: "b", h: 48 }
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/telegram.svg' width='40' height='40' /></div><br/>Telegram Resolved Notice"]
n10["<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/telegram.svg' width='40' height='40' /></div><br/>Telegram In-Progress Notice"]
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/telegram.svg' width='40' height='40' /></div><br/>Telegram Update Confirmation"]
n12@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Detect Notification Error", pos: "b", h: 48 }
n13["<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/postgres.svg' width='40' height='40' /></div><br/>Log Workflow Error"]
n14["<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/postgres.svg' width='40' height='40' /></div><br/>Lookup Ticket ID"]
n15["<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/postgres.svg' width='40' height='40' /></div><br/>Insert Reject Audit"]
n16["<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/telegram.svg' width='40' height='40' /></div><br/>Telegram Reject Alert"]
n17["<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/postgres.svg' width='40' height='40' /></div><br/>Insert Expired Audit"]
n18["<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/telegram.svg' width='40' height='40' /></div><br/>Telegram Expired Notice"]
n19["<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/postgres.svg' width='40' height='40' /></div><br/>Insert Invalid Audit"]
n20["<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/telegram.svg' width='40' height='40' /></div><br/>Telegram Invalid Alert"]
n2 --> n3
n2 --> n14
n2 --> n17
n2 --> n19
n7 --> n9
n8 --> n10
n12 --> n13
n15 --> n16
n14 --> n15
n5 --> n6
n5 --> n11
n4 --> n5
n3 --> n4
n17 --> n18
n19 --> n20
n1 --> n2
n9 --> n12
n6 --> n7
n6 --> n8
n10 --> n12
n0 --> n1
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,n6,n7,n8,n12 decision
class n3,n4,n5,n13,n14,n15,n17,n19 database
class n0 api
class n1 code
classDef customIcon fill:none,stroke:none
class n0,n1,n3,n4,n5,n9,n10,n11,n13,n14,n15,n16,n17,n18,n19,n20 customIcon
Utmaningen: ärendegodkännanden som sker “någon annanstans”
De flesta ärendesystem faller på en punkt: det mänskliga godkännandet. Ärendet finns i en databas, men beslutet tas i en chatt. Sedan uppdaterar någon status manuellt, någon annan glömmer, och din “single source of truth” blir i praktiken bara ett förslag. Det värsta är efterspelet. När en begäran ifrågasätts (“jag godkände aldrig det där”) scrollar du i Telegram-trådar, försöker matcha tidsstämplar mot ärende-ID:n och hoppas att inget har raderats.
Det adderas snabbt. Och det havererar på väldigt förutsägbara sätt.
- Godkännanden begravs i Telegram, så ärenden blir liggande i “väntar” i flera dagar.
- Statusuppdateringar sker manuellt, vilket gör att databasen och verkligheten glider isär.
- När något går fel finns det inget konsekvent revisionsspår över vem som beslutade vad och när.
- Dåliga länkar och utgångna beslut skapar förvirring, och sedan mer fram-och-tillbaka för att “bekräfta” utfallet.
Lösningen: Telegram-baserade godkännanden som uppdaterar Postgres och loggar allt
Det här flödet gör godkännanden till en kontrollerad, spårbar loop. En chef får en godkänn-/avslå-länk, klickar, och flödet fångar beslutet via en säker webhook. Innan något ändras validerar n8n länken med en HMAC-signatur plus ett utgångsfönster, så ingen kan manipulera ärende-ID:t eller återanvända ett gammalt godkännande. När den är validerad routar flödet åtgärden (godkänn, avslå, utgånget, ogiltigt), uppdaterar ärendestatusen i Postgres och skriver en matchande rad i din audit-tabell. Till sist skickas Telegram-meddelanden som bekräftar vad som hände, både till godkännaren och beställaren (hämtad från databasen).
Flödet startar i godkännande-webhooken. Sedan avgör signaturkontrollerna om anropet är giltigt. Därefter blir Postgres återigen källan till sanningen, och Telegram blir notifikationslagret i stället för systemet som “för bok” över beslut.
Vad som förändras: före vs. efter
| Det här eliminerar | Effekten du märker |
|---|---|
|
|
Effekt i verkligheten
Säg att teamet hanterar 20 ärenden per vecka som kräver godkännande. Manuellt blir det ofta 10 minuter för att skriva till chefen, 10 minuter för att följa upp senare och ytterligare 5 minuter för att uppdatera databasen och notifiera beställaren, alltså runt 8 timmar per vecka. Med det här flödet klickar chefen en gång, Postgres uppdateras direkt och båda parter får bekräftelser i Telegram. Din tid går ner till en snabb kontroll av att allt rullar och enstaka undantag, kanske 30 minuter totalt.
Krav
- n8n-instans (testa n8n Cloud gratis)
- Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
- Postgres för ärenden, revisionsspår och felloggar.
- Telegram-bot för att skicka godkännanden och statusmeddelanden.
- Miljövariabeln SECRET_KEY (sätt den i din n8n .env-fil)
Kunskapsnivå: Medel. Du är bekväm med att lägga in credentials, sätta en env-var och skapa de Postgres-tabeller som ingår.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).
Flödet i workflowet
Någon klickar på en godkännandelänk. Flödet startar när godkännande-webhooken tar emot anropet från chefens webbläsare efter att de tryckt på godkänn eller avslå.
Länken verifieras innan något ändras. Ett kodsteg validerar HMAC-signaturen och kontrollerar utgångsfönstret. Om den är utgången eller ogiltig registrerar flödet det utfallet och notifierar via Telegram så du vet att det inte var ett riktigt godkännande.
Beslutet routas och tillämpas i Postgres. En switch routar anropet till rätt väg. Godkännanden uppdaterar ärendestatusen och skriver en statusrad i audit-tabellen. Avslag slår upp ärende-ID:t (vid behov), lägger in en audit-rad för avslag och skickar sedan rätt Telegram-meddelande.
Alla får rätt notifiering. Flödet hämtar ärendeägaren från Postgres och skickar sedan en Telegram-bekräftelse samt en uppdatering till beställaren baserat på den nya statusen (pågående eller löst). Om Telegram fallerar skrivs en felrad in i din workflow_errors-tabell.
Du kan enkelt justera vem som räknas som “chef” så att det matchar din organisation, eller anpassa vilka statusar som är tillåtna utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera webhook-triggern
Skapa inkommande endpoint för godkännande som startar workflowet.
- Lägg till noden Approval Webhook Intake som din trigger.
- Ställ in Path på
/approval. - I Response Data, ställ in meddelandet till
✅ Thanks, your decision was recorded.så att godkännare får omedelbar feedback.
cid, status, action, exp och sig.Steg 2: anslut PostgreSQL för ärendeuppdateringar och revision
Flera noder uppdaterar ärenden och skriver revisionsposter i PostgreSQL.
- Öppna varje PostgreSQL-nod och anslut inloggningsuppgifter: Credential Required: Anslut era postgres-uppgifter. Detta gäller för Modify Ticket Status, Insert Status Audit, Fetch Ticket Owner, Log Workflow Error, Lookup Ticket ID, Insert Reject Audit, Insert Expired Audit och Insert Invalid Audit.
- I Modify Ticket Status, behåll Query inställd på
UPDATE tickets SET status = $2, updated_at = NOW() WHERE correlation_id = $1::uuid RETURNING id, status, updated_at, correlation_id;och ställ in Query Replacement till={{$json.correlation_id}},{{$json.new_status}}. - I Insert Status Audit, ställ in Query Replacement till
={{ $json.id }}, {{ $json.correlation_id }}, {{ $json.status }}, {{ $('Validate Signature Window').item.json.actor }}. - I Fetch Ticket Owner, ställ in Query Replacement till
={{ $('Modify Ticket Status').item.json.correlation_id }}.
correlation_id inte är ett giltigt UUID kommer Modify Ticket Status och Fetch Ticket Owner att misslyckas. Validera indata från era godkännandelänkar innan ni går i produktion.Steg 3: konfigurera validering av beslut och routing
Validera godkännandesignaturer, tillämpa utgångstid och routa beslutet till rätt flöde.
- I Validate Signature Window, ställ in Language på
pythonoch klistra in det medföljande skriptet för signaturvalidering. - Säkerställ att miljövariabeln
SECRET_KEYär satt på er n8n-instans så att HMAC-verifiering fungerar. - I Route Decision Action, behåll switch-reglerna som jämför
={{ $json["action"] }}medapprove,reject,expiredochinvalid.
SECRET_KEY saknas kommer Validate Signature Window att kasta ett fel och workflowet stoppas.Steg 4: konfigurera uppdateringar av ärendestatus och grenlogik
Godkända uppdateringar går via statusändringar, revision och förgrening för att notifiera rätt utfall.
- Koppla Route Decision Action till Modify Ticket Status (approve-sökväg), Lookup Ticket ID (reject-sökväg), Insert Expired Audit (expired-sökväg) och Insert Invalid Audit (invalid-sökväg).
- Säkerställ att Modify Ticket Status går vidare till Insert Status Audit och därefter till Fetch Ticket Owner.
- Fetch Ticket Owner skickar output parallellt till både Branch Status Check och Telegram Update Confirmation.
- I Branch Status Check, behåll villkoret att
={{ $json["status"] }}är lika medresolvedför att routa till Check Resolved State och fallback till Check In-Progress State.
Steg 5: konfigurera Telegram-notiser
Skicka notiser till användare och chefer baserat på utfall.
- Anslut inloggningsuppgifter för alla Telegram-noder: Credential Required: Anslut era telegramApi-uppgifter på Telegram Resolved Notice, Telegram In-Progress Notice, Telegram Update Confirmation, Telegram Reject Alert, Telegram Expired Notice och Telegram Invalid Alert.
- I Telegram Resolved Notice, behåll Chat ID som
={{ $json.chat_id }}och den medföljande HTML-meddelandetexten. - I Telegram Update Confirmation, behåll uttrycket för tidsstämplingsformatering
{{ new Date($("Modify Ticket Status").item.json.updated_at).toLocaleString() }}. - För admin-larm (Telegram Reject Alert, Telegram Expired Notice, Telegram Invalid Alert), ersätt Chat ID
[YOUR_ID]med ert faktiska Telegram-chat-ID.
[YOUR_ID] lämnas oförändrat kommer meddelanden att misslyckas eller inte levereras någonstans. Ange alltid ett giltigt Telegram-chat-ID.Steg 6: lägg till felhantering
Fånga notifieringsfel och logga dem till PostgreSQL.
- Säkerställ att både Telegram Resolved Notice och Telegram In-Progress Notice är kopplade till Detect Notification Error.
- I Detect Notification Error, behåll boolean-kontrollen
={{ !!$json.error }}. - Koppla Detect Notification Error till Log Workflow Error och verifiera att fälten i Query Replacement använder
{{ $workflow.id }},{{ $workflow.name }},{{ $execution.id }},{{ $json.error?.message || 'unknown' }}och{{ JSON.stringify($json) }}.
Steg 7: testa och aktivera ert workflow
Verifiera hela godkännandeprocessen innan ni slår på den i produktion.
- Klicka på Execute Workflow och skicka en testförfrågan till URL:en för Approval Webhook Intake med giltiga query-parametrar och signatur.
- Bekräfta att Modify Ticket Status uppdaterar databasen och att Insert Status Audit skapar en revisionspost för godkännanden.
- Verifiera att Telegram-meddelanden från Telegram Update Confirmation, Telegram Resolved Notice eller Telegram In-Progress Notice levereras som förväntat.
- Om ett fel inträffar, säkerställ att Log Workflow Error lägger in en rad i
workflow_errors. - När testningen är lyckad, växla workflowet till Active för att aktivera körning i produktion.
Se upp med
- Telegram-credentials kan löpa ut eller kräva specifika behörigheter. Om det strular, kontrollera BotFather-token och chat-ID:t du skickar till först.
- Om du använder Wait-noder eller extern rendering varierar processtider. Öka väntetiden om noder längre fram fallerar på tomma svar.
- Postgres-fel är ofta problem med “schema drift”. Om inserts misslyckas, kontrollera att
tickets,ticket_auditochworkflow_errorsmatchar SQL:en du deployade, och bekräfta att n8n:s DB-användare får skriva till dem.
Vanliga frågor
Oftast runt en timme när dina Postgres-tabeller och din Telegram-bot är klara.
Ja, men någon behöver hantera den initiala Postgres-setupen och miljövariabeln SECRET_KEY. I vardagen handlar det bara om att klicka godkänn eller avslå i Telegram.
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 volymer. Du behöver också räkna in kostnader för Postgres-hosting och eventuella meddelandekostnader (oftast minimala för Telegram).
Två alternativ: n8n Cloud (hanterat, enklast setup) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger obegränsade körningar men kräver grundläggande serveradministration.
Du kan ändra “chef”-logiken i flödets kodsteg (den är hårdkodad just nu) och routa olika godkännandetyper till olika Postgres-uppdateringar. Vanliga justeringar är att lägga till fler statusar, logga mer metadata i ticket_audit (som användarnamn eller IP) och byta Telegram-notifieringar mot Gmail eller ett annat chattverktyg, samtidigt som Postgres förblir system of record.
Oftast handlar det om bot-token, chat-ID:t eller att boten inte har rätt att skriva till användaren eller gruppen. Generera om token i BotFather, bekräfta målchatten och testa sedan om en enskild notifieringsnod innan du kör hela godkännandekedjan.
Om du self-hostar n8n finns ingen exekveringsgräns, men din server och Postgres sätter den faktiska gränsen. På n8n Cloud beror kapaciteten på din plan. I praktiken är godkännanden lätta, så de flesta små team kör hundratals beslut per vecka utan att ens tänka på det.
Ofta, ja. Det här mönstret bygger på säker webhook-hantering, egen validering (HMAC + utgångstid), förgrening till “ogiltig/utgången/avslå/godkänn”-vägar och att skriva flera Postgres-rader pålitligt, vilket är där n8n brukar kännas mer flexibelt. Zapier eller Make kan också göra godkännanden, men så fort du behöver tajt kontroll över signaturer, databasskrivningar och felloggning börjar du slåss med plattformen. Om du bara behöver en enkel “skicka ett meddelande, vänta på ett svar, uppdatera ett fält” kan de gå snabbare. Om du vill ha det reviderbart och manipulationssäkert är n8n en bättre match. Prata med en automationsexpert om du är osäker på vad som passar.
När godkännanden slutar leva i chatthistorik blir allt lugnare. Postgres förblir korrekt, beslut går att bevisa och du slipper leka detektiv en fredag eftermiddag.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.