Field SOP
Field SOP

Knowledge Base Auto-Update Workflow: Let Your Docs Library Keep Up With the Business

An n8n workflow for knowledge base auto-update: content source trigger -> fetch content -> dedupe -> LLM summary + keywords + classification -> vectorize and write to KB -> notify. Keeps your docs library current. Includes a .json template and advanced tips (full rescan, staleness detection, permissions).

Published August 2, 20265 min read
<!-- workflow-knowledge-base-update | resource | Knowledge Base Auto-Update Workflow: Let Your Docs Library Keep Up With the Business -->

The day you finish building a knowledge base is the day it's most up to date. It starts rotting the next morning. Product ships a doc revision without syncing the KB; ops publishes a new SOP that never gets ingested; engineering files a postmortem on GitHub Wiki that nobody pulls in; sales updates the price sheet while the KB still shows last quarter's. When a new hire searches "refund process" they get the half-year-old version, follow it, and only learn the rule changed when something breaks. The human-maintenance deadlock: the people writing docs aren't the ones ingesting them, and the people ingesting them have no idea new docs exist. The KB becomes a snapshot of history, not a reflection of current truth. This n8n workflow wires content sources (RSS, Feishu docs, GitHub Wiki, Webhook uploads) straight into the knowledge base. New docs auto-fetch, dedupe, run through an LLM for summary + keywords + classification, get vectorized and written to the KB with an index refresh, then push a Slack/Feishu message "KB updated N entries." The KB shifts from manual hauling to a self-flowing pipe-search results stay grounded in the latest docs, not last quarter's.

Workflow Chain

Content source trigger (RSS Feed Read subscribing to tech blogs / Feishu doc events / GitHub Wiki webhook / Webhook for manual upload) -> fetch full body (HTTP Request, truncate overlong) -> dedupe (Code node hashes URL + title into a key, skip if already ingested) -> LLM summary + keywords + classification (HTTP Request to Moonshot/DeepSeek, outputs title/summary/keywords/category/tags/language) -> vectorize + write to KB (HTTP Request to vector DB API for embedding + upsert, or write to Notion/Confluence/Feishu KB) -> refresh index / trigger re-rank -> notify (Slack/Feishu bot "KB updated N entries").

The core value isn't saving the one ingest click; it's shifting ingestion from "someone remembers" to "the pipe catches it." As long as a source updates, the KB follows. If search can't find new content, the cause is a missing source (check the pipe), never a forgotten ingest (check the person).

Download Template

Setup Steps

  1. Import: n8n -> Workflows -> Import from File, pick workflow-knowledge-base-update.json
  2. RSS source node: fill in your content-source RSS URL. Tech blogs use RSS Feed Read directly; Feishu docs come in via Feishu doc-event webhooks; GitHub Wiki has no native RSS, so use a Schedule Trigger polling the API or a GitHub Webhook (push event); manual uploads go through a Webhook node. Multi-source intake means normalizing fields in the Code node to title / url / content / source
  3. Fetch body node: HTTP Request GETs the doc link for the full text. RSS usually gives only a summary, so fetch the body second-pass; for HTML pages pipe through a Readability-style extractor first, otherwise nav and footer noise drags down LLM summary quality. Overlong docs get truncated to 8k chars in the Code node; the overflow is chunked and ingested separately
  4. Dedupe hash node: Code node hashes URL + title into a key, prefix kb_ to avoid clashing with other workflows. Don't hash URL alone (a renamed link slips through) or title alone (same-name docs get culled); the URL + title combo is the most stable
  5. Lookup existing node: HTTP Request queries the vector DB or store for the hash. Qdrant uses scroll + filter on hash; Pinecone uses query + metadata filter; Postgres just selects the hash column. Returns an exists flag for the next IF
  6. IF skip hit node: exists=true goes to an empty branch (ends), exists=false goes to the LLM branch. A skip is not an error-n8n logs just show "no output"
  7. LLM summary + classify node: fill in Moonshot/DeepSeek/Qwen key; 8k context is enough; prompt below. Categories are frozen to product doc / tech doc / ops manual / FAQ / announcement / other-six classes cover roughly 90% of internal KB cases; don't open ten fine-grained classes on day one
  8. Vectorize + ingest node: call the vector DB API to embed then upsert in one shot. Qdrant/Pinecone/Weaviate all support embedding + write in a single request; if your DB lacks built-in embedding, call the OpenAI/BGE embedding API first then upsert. Metadata must carry title/url/source/hash/category/updated_at for later filtering and staleness checks
  9. Notify node: Slack incoming webhook or Feishu custom bot; the message carries title + category + source link for spot-checking summary quality. Batch ingests aggregate to "N entries" rather than pushing one by one, or you'll spam the channel
  10. Test run: hand-feed one test doc (known URL), verify dedupe hits correctly, the LLM summary is reasonable, the vector DB row carries metadata, and the notification lands

Companion Prompt (LLM Summary + Classify)

Prompt
You are a knowledge-base document analyst. Read the document body below and output JSON:
- title: document title (use the original if present, otherwise infer from body)
- summary: within 150 words, covering the core conclusion not a play-by-play
- keywords: 3-5 keyword array
- category: product doc / tech doc / ops manual / FAQ / announcement / other (pick one of six, do not invent categories)
- tags: 1-3 tags
- language: zh / en
Rules: categories must come from the six given; do not fabricate facts outside the text; summarize from the original, no speculation.
Document body: {{content}}

Advanced

  • Scheduled full re-scan: a Schedule Trigger runs weekly, re-pulls all sources, hashes each and looks it up. Hit with identical content = skip; hit with changed content (content_hash differs from the stored one) triggers an "update" branch: re-summarize, re-vectorize, overwrite the old record, bump version in metadata. This is what prevents "the source changed but the KB still shows the old version"
  • Staleness detection: stamp every ingested record with updated_at; a monthly Schedule flags records untouched for 180+ days as stale, surfaces a "this doc may be outdated" banner in the KB front end, or pings the owner on Feishu. The owner field is inferred from source (Feishu doc owner, GitHub Wiki repo owner)
  • Permissions / visibility: internal KBs split into "all-staff" and "department-only." At ingest time, tag visibility by source or category, carry it in vector-DB metadata, and filter on the current user's department at retrieval. Don't dump everything into one collection and filter at the app layer; metadata filtering at the vector DB is the right path
  • Incremental vs full: default to incremental (new + changed only); run full re-scans at low frequency (weekly or monthly). Back up the current index before a full scan, diff after, and roll back on anomaly

Compliance Note

Internal KBs hold company info, customer cases, and internal processes. Before feeding an external LLM for summaries, confirm: (1) the LLM service has a Data Processing Agreement and a no-training commitment; (2) vector DB choice respects data isolation-prefer self-hosted (Qdrant/Weaviate on your own infra) or tenant-isolated SaaS (Pinecone namespaces, Weaviate multi-tenancy); (3) docs with PII or trade secrets are masked in the Code node before reaching the LLM, with the original stored internally for authorized retrieval only; (4) cross-border data transfer must satisfy PIPL and GDPR requirements-keeping the vector DB and LLM in the same region is safer.

References

This article is AI-assisted and human-edited. Last updated: 2026-08-02

Related