Watch our latest video available on Youtube.
Tutorials/Tutorial

How to Build a Knowledge Base in Airtable

Most company knowledge bases die the same death: someone builds a wiki, nobody maintains it, and within a year half the articles are wrong. Airtable fixes the maintenance problem because a knowledge base built on a database can enforce review cycles, track versions, and report on stale content the way a wiki never can. This guide is the full build — article and category schema, tagging, search, version tracking, review automations, a Softr frontend for team or customer access, and an AI layer for asking questions against the whole base. We'll also be honest about when Notion or Confluence is the better call.

Intermediate14 min readJun 11, 2026

Every company past about ten people has the same problem: the answers exist, but they live in someone's head, a Slack thread from eight months ago, or a Google Doc nobody can find. A knowledge base fixes that — if it stays accurate. And staying accurate is exactly what wikis are bad at and databases are good at.

This guide builds a complete knowledge base in Airtable: articles, categories, tags, search, version tracking, review-cycle automations, a Softr frontend for team or customer access, and an AI layer for querying the whole thing in plain English.

When Airtable Wins for Knowledge Management

Be honest about the fit before you build. An Airtable knowledge base wins when:

  • Governance matters more than prose. Review dates, owners, version logs, and stale-content reporting are native database operations. Wikis bolt them on badly or not at all.
  • The knowledge base connects to operational data. If your SOPs reference the projects, clients, or assets you already manage in Airtable, linked records turn documentation into living context.
  • You need a customer-facing help center without per-reader pricing. A Softr frontend serves unlimited visitors; Airtable seats are only needed by content editors.
  • Your content is structured. SOPs, how-tos, FAQs, policies — short, discrete, categorizable articles. This is the sweet spot.

Dedicated tools win when:

  • Notion — your knowledge base is collaborative long-form writing: specs, meeting notes, nested team wikis. The editing experience is simply better, and Plus runs $10/user/month (AI features require the $20/user Business tier).
  • Confluence — you're an Atlassian shop. Jira integration is unbeatable, Standard starts at $5.42/user/month, the free tier covers 10 users, and Rovo AI is bundled into paid plans.
  • Helpjuice — you want a polished, dedicated KB product with serious search analytics and don't mind paying for it (from $249/month).
  • Zendesk Guide — your knowledge base is fundamentally a support deflection tool tied to a ticketing system. Suite Team starts at $55/agent/month; readers are free.

If you're 60% documentation and 40% long-form collaboration, you'll be happier in Notion. If you're documenting structured, repeatable knowledge and want it governed and queryable, build it in Airtable.

Step 1: Schema

Core tables

TablePurpose
ArticlesThe content — one record per article
CategoriesTop-level navigation (one per article)
TagsGranular keywords (many per article)
VersionsSnapshot log for change tracking
FeedbackWas-this-helpful responses and article requests

Why both Categories and Tags? Categories are navigation — "Onboarding," "Billing," "IT" — and each article gets exactly one. Tags are discovery — "troubleshooting," "remote-work," "Stripe" — and each article gets several. Collapsing them into one field is the most common schema mistake; you end up with 80 "categories" and unusable navigation. For the underlying mechanics, see our linked records guide.

Articles fields

FieldTypePurpose
TitleSingle line textPrimary field
SlugFormulaURL-safe title for the frontend
SummaryLong text1–2 sentence abstract, shown in search results
BodyLong text (rich text on)The article itself
CategoryLinked record (Categories, single)Navigation
TagsLinked records (Tags, multi)Discovery
StatusSingle selectDraft / In Review / Published / Needs Update / Archived
AudienceSingle selectInternal / Customer / Both
OwnerCollaboratorWho keeps this accurate
ReviewerCollaboratorWho approves changes
Review ByDateWhen this article must be re-verified
Last VerifiedDateWhen someone last confirmed accuracy
VersionCount (Versions)Current version number — increments automatically as snapshots are created
AttachmentsAttachmentScreenshots, PDFs, diagrams
Related ArticlesLinked records (Articles, self-link)"See also"
Helpful CountRollup (Feedback)COUNT of positive feedback
Search BlobFormulaConcatenated searchable text (Step 3)
Created / ModifiedCreated time / Last modified timeAudit trail

Categories fields

Keep it minimal: Name, Description, Icon (single line — emoji works fine for Softr), Sort Order (number), and the reverse-linked Articles field with a COUNT rollup. Keep categories under ten. If you need more, your categories are actually tags.

The Slug formula

LOWER(REGEX_REPLACE(REGEX_REPLACE({Title}, "[^a-zA-Z0-9 ]", ""), " +", "-"))

This gives "How to Reset Your VPN Password" a slug of how-to-reset-your-vpn-password — useful the moment you put Softr in front of the base.

Step 2: Writing Articles

Turn on rich text for the Body field. You get headings, bold, bullet and numbered lists, checkboxes, inline code, links, and @mentions — enough for any procedural article.

Know the constraints before you commit:

  • Long text fields cap at 100,000 characters (~15,000–20,000 words), rich text or not. No real article hits this; if one does, it should be three articles.
  • Images can't be embedded inline in rich text. Use the Attachments field and reference figures by name ("see Screenshot 2"), or host images and link them. Softr can render the attachment gallery alongside the body.
  • Rich-text fields return a trailing newline via the API — harmless inside Airtable, occasionally annoying when syncing content elsewhere.

One article, one job. The strongest knowledge bases read like recipe cards, not novels: a title that matches what someone would search, a two-sentence summary, numbered steps, and a screenshot. If an article needs a table of contents, split it and connect the pieces with Related Articles.

Step 3: Search and Discoverability

Search is where knowledge bases live or die, and you have three layers to get right.

The Search Blob formula

Airtable's view search bar scans the fields visible in the current view, and frontend search — Softr or Interfaces — is pointed at specific fields. All of it is literal matching, and users think in synonyms. Build a formula field that concatenates everything searchable into one place:

{Title} & " " & {Summary} & " " & ARRAYJOIN({Tags}, " ") & " " & {Category}

Add a Keywords long text field to the schema for synonyms and misspellings users actually type ("wifi," "wi-fi," "wireless"), and append it to the blob. Now a search against one field matches title, summary, tags, category, and synonyms simultaneously. This single field is the highest-leverage search improvement in the whole build — and it powers Softr's search too.

Editor-side views

  • All Articles — grid, grouped by Category, for content managers.
  • Published — filter Status = Published, what the frontend shows.
  • Needs Review — filter Review By <= TODAY() and Status is Published, grouped by Owner. The accountability view.
  • Drafts In Flight — Status is Draft or In Review, sorted by Modified.
  • Most Helpful / Least Helpful — sorted by the Helpful Count rollup, for deciding what to improve next.

Interface for internal browsing

For teams that live in Airtable, build a browsing page in Interface Designer: a record list element (which includes built-in search) filtered to Published, with category filters, and a record detail view showing the rich-text Body. For pure internal knowledge bases, this can be the entire frontend — no extra tools, no extra cost.

Step 4: Version Tracking

Airtable's built-in record revision history works, but it's buried in the activity feed and editors can't scan it. A Versions table makes change history a first-class citizen.

Versions fields

FieldTypePurpose
Version NameFormula{Article} & " v" & {Version Number}
ArticleLinked record (Articles)Parent
Version NumberNumberSequential
Body SnapshotLong text (rich text)Frozen copy of the body
Change SummaryLong textWhat changed and why
Changed ByCollaboratorAuthor
Snapshot DateCreated timeWhen

The snapshot automation

  1. Trigger: When an Article record matches conditions — Status changes to "Published."
  2. Action: Create a record in Versions, copying Body into Body Snapshot.
  3. Action: Update the Article — set Last Verified to today.

One wrinkle: a plain "Update record" action can't do arithmetic, so don't try to increment Version inside the automation. The clean fix is to make Version on Articles a Count field over the linked Versions records — every snapshot bumps it automatically — and stamp Version Number on the snapshot from that count (or with a one-line scripting action if you want strict sequencing).

Every publish event now produces a permanent, readable snapshot. When someone asks "what did the refund policy say in March?", you open the Versions table instead of archaeology in revision history. For regulated teams (HR policies, compliance SOPs), this table is the audit trail.

Step 5: Review-Cycle Automations

Stale content is how knowledge bases die. The fix is structural, not motivational: every article has an Owner and a Review By date, and automations do the nagging.

Review reminder (weekly)

  1. Trigger: Scheduled, Monday 9 AM.
  2. Find records: Articles where Review By <= 14 days from now AND Status = Published.
  3. Action: Slack DM or email each Owner their list. One message per owner, not per article — nobody reads twelve separate pings. (Grouping found records by owner takes a short scripting action; a plain repeating group would fire once per article.)

Auto-flag overdue content

  1. Trigger: Scheduled, daily.
  2. Find records: Articles where Review By < TODAY() AND Status = Published.
  3. Action: Update Status to "Needs Update." If your Softr frontend filters on Published, genuinely overdue content silently drops out of the public KB until someone re-verifies it. That's a feature: a wrong answer is worse than no answer.

Review cadence by content type

Set Review By at publish time based on volatility: pricing and product content every 3 months, process SOPs every 6, policies every 12. A simple formula default works: DATEADD({Last Verified}, 6, 'months').

Approval flow for new articles

When Status changes to "In Review," notify the Reviewer with a record link. Reviewer approves by flipping Status to Published — which fires the version snapshot from Step 4. Two automations, and you have an editorial workflow that Confluence charges Premium prices for. (The same pattern powers our approval workflow guide.)

Step 6: The Softr Frontend

Airtable is a great backend and a mediocre reading experience. Softr fixes that with a help-center-grade frontend in an afternoon — and it's the same stack we use for client portals.

The build

  1. Start from Softr's knowledge base template and connect your Airtable base. The template ships list, search, and detail pages out of the box.
  2. List page: category cards (from the Categories table, sorted by Sort Order), a search bar wired to the Search Blob field, and tag filters.
  3. Detail page: Title, Summary, rich-text Body (Softr renders Airtable rich text cleanly), attachments, Related Articles, and a "Was this helpful?" form writing to the Feedback table.
  4. Filter everything to Status = Published — this is what makes the auto-flag automation in Step 5 act as a kill switch for stale content.
  5. Access control: public pages for a customer help center, or logged-in user groups for internal/customer splits using the Audience field. For the Airtable-side permissions model, see our permissions guide.

Cost reality

Softr's free plan covers up to 1,000 records per app and 10 app users — and even includes a custom domain — enough to launch most internal KBs. Basic is $49/month billed annually ($59 monthly) with 20 app users; Professional at $139/month annual ($167 monthly) raises that to 100. Crucially, readers never need Airtable seats. Five editors on Airtable Team ($20/editor/month annual) plus Softr Basic is roughly $150–160/month for a knowledge base serving unlimited public readers — against Helpjuice's $249/month floor or Zendesk's $55 per agent.

Step 7: AI Over the Knowledge Base

A 2026 knowledge base shouldn't just be searchable — it should be askable.

Airtable AI inside the base

All Airtable plans — including Free — now include pooled monthly AI credits (per-seat AI pricing ended in June 2025; Team includes 15,000 credits per seat, and extra packs run $40/month for 20,000 credits). Two high-value uses:

  • AI summary field — generate the Summary from the Body automatically, so search results and Softr cards always have a clean abstract.
  • AI tagging — suggest Tags from the Body on creation, keeping the taxonomy consistent across authors.

More patterns in our practical Airtable AI guide.

Q&A via MCP

Connect the base to Claude through the Airtable MCP server and your knowledge base becomes conversational: "What's our refund policy for annual plans?" returns an answer sourced from the actual Published articles — schema-aware, current, and without retraining anything. Because your KB is structured data rather than a pile of pages, the AI can filter by Status, Audience, and Category before answering, which is precisely what makes database-backed knowledge bases age better than wikis. Full setup in our MCP server and AI agents guide.

Comparison: Airtable + Softr vs Dedicated KB Tools

FactorAirtable + SoftrNotionConfluenceHelpjuiceZendesk Guide
Entry costFree–$79/mo typical$10/user/mo (Plus)$5.42/user/moFrom $249/mo$55/agent/mo (Suite)
Readers free?Yes (Softr public)Paid for membersPaid per userPublic only (internal readers are paid users)Yes
Writing experienceGood (rich text)ExcellentVery goodVery goodGood
Review-cycle governanceExcellent (native automations)WeakModerateGoodModerate
Version audit trailExcellent (Versions table)Page historyPage historyGoodGood
Links to operational dataNativeLimitedLimitedNoNo
Public help centerVia SoftrPublic pages (basic)Add-onsNativeNative
Best forStructured SOPs + governance + ops integrationCollaborative team wikisAtlassian shopsKB-only at scaleSupport deflection

Common Mistakes

Mistake 1: One mega-table with a "Type" field instead of Categories and Tags tables. You lose category metadata (descriptions, icons, sort order) and the frontend navigation suffers immediately.

Mistake 2: No owner per article. "The team" owns nothing. Every article gets exactly one Owner collaborator, and the Needs Review view is grouped by that field so neglect has a name attached.

Mistake 3: Skipping the Search Blob. Users search "wifi" and the article says "wireless network." Without a synonyms-aware formula field, your search fails on vocabulary, and users conclude the KB is useless after two failed searches.

Mistake 4: Publishing without review dates. An article without a Review By date is stale content with a delay timer. Make the field required in your publish automation's conditions.

Mistake 5: Building the Softr frontend before the content. Ship 20 genuinely useful articles to a plain Interface first. A beautiful help center with six articles trains everyone to never come back.

Troubleshooting

Rich text looks wrong in Softr. Confirm rich text is enabled on the field in Airtable, and that the Softr detail block is set to render rich text rather than plain text.

Search returns too little. The search is pointed at Title only. Point it at the Search Blob field, and check the blob formula actually includes Tags via ARRAYJOIN().

Version snapshots aren't firing. The automation triggers on Status changing to Published — re-saving an already-published article won't fire it. Add a second automation triggered on Body's last-modified time if you want every edit snapshotted (Airtable automations allow only one trigger each).

Review reminders ping the wrong people. Owner fields go stale when people leave. Add an offboarding step: filter Articles by departing Owner, bulk-reassign.

Articles vanish from the frontend unexpectedly. The overdue automation flipped them to Needs Update — working as designed. Check the Needs Review view; someone owes a verification pass.

Next Steps

A knowledge base earns its keep when it stops being a side project and starts being infrastructure. Once the core build is live, the natural extensions:

  • Feedback loop — review the Feedback table monthly; low-rated and most-searched-but-missing topics drive the writing queue.
  • Support integration — link Articles to your tickets or CRM records so resolutions become documentation.
  • Content production pipeline — if you're publishing at volume, run drafting and approvals through a content calendar feeding the same Articles table.
  • Conversational access — wire the MCP connection into your team's AI tooling so the KB answers questions in Slack and Claude, not just in a browser.

If you're scoping a knowledge management system that ties into the rest of your Airtable operations — projects, clients, support — that's exactly the kind of build we do. Get in touch.

Frequently Asked Questions

Common questions about this tutorial.

Ready to Transform Your Business Operations?

Join 100+ companies that have automated their way to success. Get started today and see the difference.