Skip to main content
You can author knowledge bases directly in Serval — no external wiki required. You write pages in a rich block editor, publish them when they’re ready, and the help desk agent searches and cites them like any other knowledge source. Knowledge bases you author live in the Knowledge Bases tab of the Knowledge section, alongside the Knowledge Sources tab that manages synced content.
Knowledge bases are in beta.
When you create a knowledge document, including when acting on a knowledge suggestion, you can choose one of your Serval native knowledge bases as the destination, in addition to any connected external sources.

​
Creating a knowledge base

  1. In the sidebar, open Knowledge, then select the Knowledge Bases tab
  2. Click New knowledge base and give it a name (for example, “IT Handbook”)
  3. Add pages and folders to build out your content
Each knowledge base has a name and an icon you can customize. Your team can create as many knowledge bases as it needs — for example, one per department or per topic area.

​
Pages and folders

Content is organized as a tree:
  • Pages are documents you write in the block editor. Pages can nest under other pages, so a page is also a container for its children.
  • Folders are pure grouping containers for pages.
Drag items in the sidebar to reorder or move them.

​
Copy an external page into a knowledge base

Pages under From your apps come from their connected source. Opening an empty source keeps it empty until pages sync; it doesn’t create an editable starter page. To turn read-only synced content into a page you can edit, open a page (or folder) under From your apps in the sidebar and choose Copy to Serval. Pick which authored knowledge base the editable copy should live in. Copying a folder brings everything inside it, and the original stays connected to its source, so the synced version keeps updating alongside your editable copy. Copies can only land in a knowledge base you author in Serval, not in another connected source’s tree.

​
Writing content

Pages use a block editor with the formatting you’d expect from a modern wiki:
  • Paragraphs and headings (H1–H3)
  • Bulleted, numbered, and checklists
  • Quotes, code blocks, and dividers
  • Tables
  • Images — paste, drag-and-drop, resize, and caption
Two inline shortcuts speed up writing:
  • Type [[ to link to another page in the same knowledge base
  • Type @ to mention a teammate
Everything autosaves as you type — a “Saving…” indicator appears while a write is in flight.

​
Drafts, publishing, and versions

Pages follow a draft → publish model:
  • Every page starts as a draft. Only published pages are indexed for agent retrieval — you can iterate freely without half-finished content reaching users.
  • Clicking Publish (or Publish changes) snapshots the current content as a new version. When approval is required, choose Submit for approval, or Update submission if a revision is already pending. The version pill in the header (for example, v3) shows a green dot when the live version is published and current, and an amber dot when there are unpublished changes.
  • Version history shows the timeline of published revisions — autosaves don’t create versions, so history stays meaningful.
  • Compare two versions from version history to see a word-level diff of what changed between them.
  • Restore a previous version from version history: Serval brings it back as a draft, so you can review it and publish to make it live.
  • Unpublish retracts a page: the agent stops searching it and read-only viewers lose access.
After you publish, an indexing status badge shows where the page is in the search pipeline: Synced & searchable, Indexing, or Index failed (with a retry option for publishers).

​
Require approval to publish

A team can require an approver to sign off before a submitted revision reaches readers. Open Knowledge → Approvals to set the Team default, which is off until enabled. Knowledge bases, pages, and sources can have their own rules, so a page can require approval even when the team default is off. The publishing approval control offers three choices:
  • Use default follows the closest applicable rule, including future changes to it.
  • Require approval sets an explicit review requirement.
  • Publish without approval sets an explicit exception, even if a broader rule requires review.
A page’s own rule takes priority, followed by its nearest parent page or folder, the remaining ancestors and knowledge base, its source, and finally the team default. More specific exceptions can override a broader review requirement. These rules control publishing review; they do not change who can read or edit knowledge. When a native page requires approval:
  • Submit for approval snapshots the revision and puts it in the approval queue instead of making it live. Readers keep the revision that was already published.
  • An approver with the approve knowledge document permission approves or rejects it from the queue. Approving publishes it; rejecting leaves the previous revision live.
  • You cannot approve your own submission. Someone else has to review it.
  • Update submission replaces a pending revision with the current draft. A rejected revision is final; edit the page and submit again to start a new decision.
  • Turning approval off does not release revisions already waiting. An approver must decide on them, or the author can submit or publish again under the current rule.

​
Proposals on synced articles

Accepting a proposal on an externally synced article changes the content Serval serves without a separate draft or pending revision. If the article’s effective publishing rule requires approval, Serval refuses the proposal and leaves the article unchanged. It does not put synced articles or incoming source updates in the publish approval queue; review and publish those changes in the source system instead. Because it publishes, accepting an article proposal needs permission to publish knowledge documents — the same permission the Publish button needs. Someone who can review change sets but not publish knowledge gets a clear refusal, and the article is left untouched. An article synced from a connected source can take a proposal. When you accept one, the accepted text becomes the article Serval serves, and later syncs from the source no longer overwrite it. Serval also pushes the change back to the source system where the connector supports it (Notion, Confluence, ServiceNow, Freshservice and Slab today); where it does not, the accepted text still stands in Serval. Proposals are also refused in these cases:
  • The source article changed after the proposal was written. Read the article again and propose again.
  • The article links to other Serval pages or mentions people. A proposal is plain markdown and cannot carry those references, so edit the page in the editor instead.

​
Organizing and finding content

  • Search — full-text search across pages from the sidebar
  • Favorites — star pages for yourself; favorites are personal
  • Pinned — pin pages for the whole team; everyone sees the same pinned set
  • Archive — archiving moves a page, or a whole knowledge base, to Archive, where it can be restored or permanently deleted
Pages also support duplicate, move (to another parent or knowledge base), and copy link from the page actions menu.

​
Access control

Knowledge bases authored in Serval have two independent layers of access control:
Workspace access controls who can view and edit pages inside Serval. Help desk audience controls who the agent surfaces a page to when answering requests.

​
Workspace access

Team roles govern who can view, create, edit, publish, archive, and delete authored knowledge content. Members with read-only access see published pages with a read-only banner — they never see drafts or version history.

​
Help desk audience

Open Access from a page’s actions menu in the sidebar or its header. Select access profiles and click Save visibility to update who can find the page in the help desk. For a nested page or folder, Inherit parent visibility controls how its audience combines with its parent:
  • On: the page includes the parent audience plus anyone matching a profile selected on this page. Later parent changes flow through automatically. Any inherited blocked profiles still exclude matching users.
  • Off: only the page’s own profiles apply. With no profiles selected, anyone in the org can find it.
For example, if a parent allows Engineering and its child inherits while adding Finance, Engineering and Finance can find the child. The parent still shows Engineering. If the child turns inheritance off, only Finance can find it. The same rules apply at each level of a nested tree; child settings never change the parent’s audience or its display. The Access panel lists the inherited audience separately from the profiles added on this page. If the parent already allows anyone in the org, adding profiles cannot narrow that inherited audience. Turn inheritance off to set a narrower audience on the child. Existing pages keep their audience when this option becomes available: pages with their own profiles start with inheritance off; pages without their own profiles inherit. Restricting the help desk audience does not change who can view or edit the page in the workspace — the two layers are separate. To restrict a whole knowledge base, set its audience from the base’s actions menu → Visibility, or add the base to an access profile. See Restricting knowledge bases. The same Access panel shows the saved audience and why each profile is Allowed or Blocked. Use Check a person to see whether a specific user can find the page, and why. Unsaved visibility changes do not affect these checks; click Save visibility to apply them.

​
AI-context-only knowledge bases

A knowledge base can be marked AI context only: its content is indexed for agent retrieval but hidden from human-facing surfaces. Use this for internal reference material the agent should know without exposing it as browsable documentation.

​
Owners

Every knowledge base and page you author in Serval can have Owners: the users or groups accountable for keeping that content correct. Ownership is separate from access, so naming an owner doesn’t change who can read or edit the content. Set owners from the Owners action in a knowledge base’s actions menu, or the Owners control in a page’s header. Anyone who can browse the knowledge base sees the current owners; changing them requires edit access to the base.

​
How the agent uses authored knowledge

When a user submits a request, the help desk agent searches your published pages together with all other knowledge sources. Answers cite the page with a View in Serval link that deep-links straight to it.

​
Learn more