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

PostgreSQL till Slack: smartare inköpslarm

Rickard Andersson Partner, Nodenordic.se

Att hålla ingredienskostnaderna under kontroll är frustrerande eftersom jobbet aldrig tar slut. Priser rör sig, leverantörer ändras, någon skärmdumpar ett kalkylblad, och du upptäcker för sent att du borde ha köpt förra veckan.

Den här uppsättningen för Postgres Slack alerts träffar restaurangoperatörer och inköpsansvariga hårdast. Men analytiker på byråer som bygger rapportering åt kunder inom hospitality hanterar samma kaos. Resultatet är enkelt: daglig uppföljning, trendkontext och ett tydligt “köp nu / vänta / fyll på lager”-budskap levererat automatiskt.

Du får se hur detta n8n-flöde samlar in priser, bygger en verklig historik i PostgreSQL, genererar rekommendationer och skickar rätt insikt till Slack (plus en e-postdashboard).

Så fungerar automationen

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

n8n Workflow Template: PostgreSQL till Slack: smartare inköpslarm

Problemet: ingredienspriser ändras snabbare än din process

Om du köper in till en restaurang (eller rådgör åt en) känner du redan igen mönstret. Någon kollar en leverantörsportal, kopierar en siffra till ett ark och kallar det “uppföljning”. Sedan sticker priset, du missar läget att låsa en lägre nivå och veckans marginal får en smäll utan att någon riktigt märker det. Det värsta är den mentala belastningen. Du bevakar inte bara en ingrediens; det är dussintals, över enheter, leverantörer och tidslinjer. Även ett litet fel (fel enhet, fel datum, gammalt pris) gör din “trend” värdelös.

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

  • Manuella stickprov gör att du reagerar sent, ofta först när fakturorna kommer.
  • Utan en riktig databashistorik kan du inte säkert avgöra om dagens pris är en tillfällig avvikelse eller början på en uppgång.
  • Team hamnar i Slack-diskussioner om inköp utan full kontext, vilket leder till “vi avvaktar”-beslut som kostar mer senare.
  • Kalkylbladsbaserad uppföljning driver ofta iväg, och felen syns exakt när du behöver korrekt formaterade siffror.

Lösningen: daglig prisuppföljning med trendbaserade köpsignaler

Det här flödet kör en schemalagd scan varje dag, hämtar senaste ingredienspriserna från ett externt prissättnings-API (eller valfri källa du pekar ut) och lagrar varje snapshot i PostgreSQL. Därefter frågar det ut de senaste 30 dagarnas historik för att beräkna trendriktning och senaste rörelse, och skapar sedan en praktisk rekommendation som BUY_NOW, WAIT eller STOCK_UP med en etikett för brådska. Till sist bygger det en enkel HTML-dashboard för helhetsbilden, mejlar den till intressenter och postar de viktigaste varningarna i Slack så att teamet ser beslutet i rätt tid. Du sätter upp det en gång, sedan blir din “uppföljning” ett faktiskt system.

Flödet startar på ett dagligt Cron-schema och gör en HTTP-förfrågan för att hämta aktuella priser. PostgreSQL sköter lagring och 30-dagarsanalys, och sedan sparas vägledningen och återanvänds för att generera både e-postdashboarden och Slack-notisen.

Det du får: automation vs. resultat

Exempel: så här ser det ut

Säg att du följer 20 kärningredienser hos 2 leverantörer. Manuell hantering är ungefär 2 minuter för att kontrollera och logga varje pris, vilket blir runt 80 minuter per dag om du faktiskt är konsekvent (det är de flesta team inte). Med det här flödet är “arbetet” i princip noll: Cron-triggern kör, API-hämtningen sker, PostgreSQL lagrar snapshoten och Slack får köp-/vänta-uppmaningen. Du kanske lägger 5 minuter på att skumma dashboard-mejlet och går sedan vidare med dagen.

Det du behöver

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • PostgreSQL för att lagra prishistorik och rekommendationer
  • Slack för att ta emot köp-/vänta-varningar i en kanal
  • API-nyckel för ingredienspriser (hämta den från din leverantör av prisdata)

Kunskapsnivå: Medel. Du kopplar konton, klistrar in inloggningsuppgifter och verifierar ett par databasfrågor och webhook-inställningar.

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

Så fungerar det

Dagligt schema startar allt. En Cron-trigger kör en gång per dag så att du bygger konsekvent historik utan att behöva komma ihåg det.

Nya priser hämtas och normaliseras. n8n hämtar aktuella ingredienspriser via HTTP Request och förbereder sedan fält som ingrediensnamn, enhet, leverantör och tidsstämpel så att de hamnar strukturerat i PostgreSQL.

Trender och vägledning skapas från verklig historik. PostgreSQL frågar ut de senaste 30 dagarna för att beräkna trendmått, sedan bygger flödet inköpsvägledning och lagrar den i en rekommendationstabell för rapportering.

Slack + e-post levererar beslutet. Flödet skapar en HTML-dashboard och skickar den via e-post, medan Slack får en fokuserad varning som lyfter vad som ändrats och vad ni ska göra härnäst.

Du kan enkelt ändra 30-dagarsfönstret till 14 dagar (mer reaktivt) eller 60 dagar (stabilare) beroende på behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementation

Steg 1: Konfigurera den schemalagda triggern

Ställ in arbetsflödet så att det körs enligt ett schema och startar både datainhämtningen och databasiniteringen parallellt.

  1. Öppna Scheduled Price Scan och definiera ert föredragna cron-schema (t.ex. dagligen vid en specifik tid).
  2. Bekräfta exekveringsflödet så att Scheduled Price Scan skickar utdata till både Retrieve API Costs och Initialize Database Tables parallellt.
  3. Lämna Flowpast Branding som en referensnotering (valfritt för körningen).

Parallell exekvering säkerställer att databasschemat är klart medan API-data hämtas, vilket minskar risken för insert-fel.

Steg 2: Koppla API- och databaslagret

Konfigurera HTTP-anropet för att hämta ingredienspriser och säkerställ att alla Postgres-noder är anslutna till samma databas.

  1. I Retrieve API Costs ställer ni in URL till https://api.example-food-prices.com/ingredients.
  2. Öppna Initialize Database Tables och verifiera att Operation är inställt på executeQuery med den medföljande SQL:en för att skapa tabellerna.
  3. Anslut Postgres-inloggningsuppgifter till alla databasnoder (5 totalt): Initialize Database Tables, Persist Price Records, Compute Trend Metrics, Save Guidance Results och Retrieve Dashboard Info.

Autentiseringsuppgifter krävs: Anslut era postgres-inloggningsuppgifter

⚠️ Vanlig fallgrop: Om tabellerna inte finns kommer Persist Price Records att misslyckas. Säkerställ att Initialize Database Tables körs och pekar på rätt databasschema.

Steg 3: Sätt upp trendanalys och köprekommendationer

Det här steget beräknar trendmått för 30 dagar och genererar lättlästa köprekommendationer.

  1. I Persist Price Records ställer ni in Table till price_history och behåller mappningen inställd på automatisk mappning av indata.
  2. Öppna Compute Trend Metrics och bekräfta att Operation är executeQuery med hela SQL-frågan inkluderad i arbetsflödet (30-dagars trendfönster).
  3. I Build Buying Guidance behåller ni JavaScript-logiken som den är för att mata ut rekommendationsfält som BUY NOW, WAIT och angelägenhetsgrad.

Om ni vill ha andra tröskelvärden för “BUY NOW” eller “AVOID BUYING” redigerar ni de villkorliga värdena i Build Buying Guidance.

Steg 4: Spara och förbered data för dashboard

Spara rekommendationer och sätt ihop dashboard-data som används för meddelanden och rapportering.

  1. I Save Guidance Results ställer ni in Table till buying_recommendations och låter automatisk mappning vara aktiverad.
  2. Öppna Retrieve Dashboard Info och verifiera att Operation är executeQuery med den angivna sorteringslogiken för angelägenhet.
  3. I Compose Dashboard Markup behåller ni HTML-mallen intakt för att generera en fullständig dashboard i $json.html.

Dashboarden innehåller summeringar och kort som är stylade efter angelägenhet. Ni kan justera färger eller layout direkt i Compose Dashboard Markup.

Steg 5: Konfigurera utleverans av rapporter

Skicka HTML-dashboarden via e-post och posta en Slack-sammanfattning parallellt.

  1. I Dispatch Email Report ställer ni in To Email till [YOUR_EMAIL] och From Email till [YOUR_EMAIL].
  2. Ställ in Subject till Daily Price Fluctuation Report - {{ $now.format('YYYY-MM-DD') }}.
  3. I Dispatch Email Report behåller ni bilagan inställd på data:text/html;base64,{{ $json.html | base64 }} så att HTML-dashboarden renderas korrekt.
  4. I Post Slack Notification ställer ni in URL till https://hooks.slack.com/services/[YOUR_ID] och behåller Send Body aktiverat.
  5. Verifiera att Slack-meddelandet använder uttrycken: 🍽️ Daily Price Update: {{ $('Retrieve Dashboard Info').all().filter(item => item.json.urgency === 'HIGH').length }} high priority items need attention! och bilageuttrycket ={{ $('Retrieve Dashboard Info').all().filter(item => item.json.urgency === 'HIGH').map(item => ({ color: item.json.recommendation === 'BUY NOW' ? 'good' : 'danger', fields: [{ title: item.json.ingredient, value: `${item.json.recommendation} - ${item.json.reason}`, short: false }] })) }}.
  6. Bekräfta att Compose Dashboard Markup skickar utdata till både Dispatch Email Report och Post Slack Notification parallellt.

Autentiseringsuppgifter krävs: Anslut era smtp-inloggningsuppgifter

⚠️ Vanlig fallgrop: Om Slack-webhook-URL:en är ogiltig kommer arbetsflödet att misslyckas vid Post Slack Notification även om e-posten lyckas.

Steg 6: Testa och aktivera ert arbetsflöde

Validera processen end-to-end och aktivera schemat för användning i produktion.

  1. Klicka på Execute Workflow för att köra ett manuellt test från Scheduled Price Scan.
  2. Bekräfta att Persist Price Records lägger in data i price_history och att Save Guidance Results skriver till buying_recommendations.
  3. Verifiera att e-posten kommer fram med HTML-dashboarden som bilaga och att Slack-meddelandet innehåller högprioriterade objekt.
  4. När ni är nöjda växlar ni Active för att aktivera de schemalagda körningarna.
🔒

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

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • PostgreSQL-inloggningar kan löpa ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera din n8n-credential och bekräfta att databasanvändaren kan CREATE/INSERT/SELECT först.
  • Om du använder Wait-noder eller extern rendering varierar bearbetningstiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
  • Slack-webhooks och bot-tokens roteras i vissa organisationer. Om varningarna plötsligt slutar, kontrollera Slack-credentialen igen och bekräfta att kanalen fortfarande tillåter inkommande inlägg.

Vanliga frågor

Hur lång tid tar det att sätta upp denna Postgres Slack alerts-automation?

Cirka 45 minuter om din åtkomst till PostgreSQL och Slack är klar.

Behöver jag kodkunskaper för att automatisera köpnotiser för ingredienser?

Nej. Du klistrar mest in inloggningsuppgifter och justerar några fält och tröskelvärden. Den enda “tekniska” delen är att bekräfta att din databasanslutning fungerar.

Är n8n gratis att använda för detta Postgres Slack alerts-flöde?

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 med kostnaden för ditt API för ingredienspriser (varierar mellan leverantörer).

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

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 dig obegränsat antal körningar men kräver grundläggande serveradministration.

Kan jag anpassa detta Postgres Slack alerts-flöde för veckorapporter i stället för dagliga?

Ja, men du bör ändra två saker. Uppdatera Cron-schemat så att det kör veckovis och justera sedan fönstret i trendfrågan i delen Compute Trend Metrics så att den fortfarande använder tillräckligt med data för att vara meningsfull. Vanliga justeringar är också att ändra tröskeln för “brådska”, lägga till leverantörsspecifika regler och begränsa Slack-pingar till enbart HIGH-brådskande poster.

Varför misslyckas min PostgreSQL-anslutning i det här flödet?

Oftast handlar det om användarbehörigheter i databasen eller fel host/port i dina n8n-credentials. Bekräfta att användaren kan skapa tabeller (för den initiala uppsättningen) och infoga/selekttera rader (för dagliga körningar). Om du använder en hanterad Postgres-tjänst, kontrollera även IP-allowlists och SSL-krav eftersom de inställningarna tyst blockerar anslutningar.

Hur många prisposter kan denna Postgres Slack alerts-automation hantera?

Väldigt många. De flesta restauranger kan lagra månader (eller år) av dagliga priser utan att belasta PostgreSQL, och 30-dagars trendfrågan förblir snabb om du har index aktiverade. På n8n Cloud är den praktiska gränsen dina månatliga körningar; om du kör själv beror det främst på serverstorlek och hur många ingredienser du följer.

Är denna Postgres Slack alerts-automation bättre än att använda Zapier eller Make?

För det här användningsfallet, oftast ja. Flödet bygger på en riktig databashistorik och SQL-frågor, vilket är krångligt (och ofta dyrt) att modellera med Zapier-liknande stegbegränsningar. n8n gör det också enklare att förgrena logik, spara mellanresultat och skapa en dashboard utan att göra allt till en skör kedja av zaps. Zapier eller Make kan fortfarande fungera om du bara behöver en enkel “priset ändrades, skicka meddelande”-notis och du inte bryr dig om trendkontext. Om du är osäker, prata med en automationsexpert och beskriv hur många ingredienser du har och hur ofta du köper.

När detta väl rullar slutar du jaga priser och börjar agera på dem. Flödet tar hand om det repetitiva, och teamet får tydligare inköpsbeslut i Slack utan det dagliga kaoset.

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

Launch login modal Launch register modal