How many nesting levels?

No limit — build the tree as deep as you need.

Does it search inside pages?

Yes — full-text search across content and headings.

How do permissions work?

Page owner picks: everyone / team / specific people / public.

Yes — to PDF or Markdown, single page or whole tree.

All features

Pages

Pages and knowledge base

Hierarchical pages with subpages, embeds, search and permissions — an internal wiki without separate tools.

Built for

Knowledge teams
Onboarding
Product teams
HR

Try Now See pricing

Wiki · Engineering

Workspace › Engineering › Architecture

Architecture overview

How the platform works: services, data and integrations — a quick overview for new engineers.

sub-pages2

Deploy runbook

On-call SLA

#internal#eng#v2

AKIOMV3 editorsupdated today

By the numbers

∞

nesting levels

Easylim CRM

instant full-text search

customer data

Real-time

multi-user editing

2025 survey

How it works

New-hire onboarding

A hub with all first-week instructions — structured and searchable.

Product docs
Team wiki

How it works

Standard Operating Procedures

Processes, regulations, checklists — in one tree.

Client portal
Training

Deep dive

A team knowledge base — how to build one a new hire can search in 30 seconds

5 chapters

In most teams the knowledge base looks like this: 200 Google Docs with no structure, four Notion workspaces nobody has updated since 2023, and a Slack channel called "#how-do-i" where new hires ask the same questions every morning. Pages in Easylim are an attempt to collect everything into one tree and keep documentation living next to the tasks, not in a separate tool. Here's how to build that tree so it doesn't become a graveyard of stale SOPs a year from now.

Розділ

What pages are and how they differ from documents

Pages are a hierarchical wiki: one page contains subpages, those contain their own subpages, all the way down. In a document everything is linear (top to bottom); in pages there's a tree — like a filesystem, but without files.

This is a fundamentally different way of storing knowledge. A document lives for weeks (brief, PRD, contract) — then gets archived. A page lives years: "How we deploy", "New-hire onboarding SOP", "Platform architecture", "Coding standards". Content that has to be up to date every single day.

Easylim keeps pages in the same sidebar as tasks. So when you open a project, you see both the Kanban and the associated documentation — without alt-tabbing to Notion, Confluence, or GitHub Wiki. One context, instead of three browser tabs.

Page = tree with subpages. Document = linear text.
Pages for content that lives years. Documents for working text over weeks.
One sidebar holds both tasks and wiki — no tool switching.

wiki · nested tree

Workspace

📁Getting started

📂Marketing

▾📂Brand

▸📄Tone of voice

▸📄Logo usage

▸📁Campaigns

📁Engineering

📁Sales playbook

∞ nesting levels8 of 124 pages

Розділ

How to build a knowledge tree people can actually search

The biggest mistake — creating 50 root pages with no grouping. Two months in, the sidebar is unreadable, search returns 30 results with identical names, and the team goes back to Slack.

A working starter skeleton — 4–6 root sections by function: Getting Started / Engineering / Product / Sales / People / Company. Each one becomes its own branch of the tree, with subpages for specific topics. Three or four levels deep is the sweet spot — beyond that it's a maze.

Naming is 80% of usability. Not "Document 14" — "Deploy runbook · production". Not "API notes" — "API · authentication endpoints". The title should answer: "if I'm searching for this six months from now, what word will I type?"

Embed blocks turn a page into living documentation: embed Loom videos for procedures, Figma for the design system, Easylim tasks for active RFCs. If content is needed in two places, use a Synced Block instead of copying. Edit one, and all copies update.

4–6 root sections, not 50 — otherwise the sidebar becomes a dump.
3–4 levels deep maximum — past that, people stop clicking.
Titles as search queries — what word will you search a year from now?

wiki page · TOC

On this page

Overview
Services
Data flow
Deploy
On-call SLA

Architecture overview

How the platform works — services, data and integrations.

# Services

# Data flow

Розділ

Search, permissions, owner-and-review — what separates a wiki from a graveyard

Full-text search is the foundation a wiki stands on. Easylim indexes titles, content, tables, even code blocks. Cmd+K and in 200ms you get a list of relevant pages with snippet context around the match.

Page-level permissions with inheritance: set permissions on a root page, all subpages inherit. You can lock down one subpage separately (e.g. "Salaries" in People — HR only). Owner, team, specific people, public, or "anyone with the link".

Owners and review cycles are the single best thing you can do to keep the wiki from dying. Every page has an owner. Once a quarter Easylim shows that owner a list of their pages: "check whether this is still accurate". Pages not reviewed in 6+ months get flagged "stale" — search shows them with a warning.

Backlinks — Easylim shows at the bottom of every page a list of everything that links to it. Massively useful when you refactor docs: you can see that updating "API auth" means you also need to update 4 related pages.

Cmd+K — search across the whole tree in 200ms.
Owner + quarterly review — so pages don't quietly rot.
Backlinks expose dependencies — so you don't forget what to update.

page permissions

🌐

Sales playbook

updated 2d ago

Public

👥

Architecture overview

updated 2d ago

Team

🔒

Salaries — Q3

updated 2d ago

Private · HR

permissions inherit from parentoverride

Розділ

A week with a living knowledge base

Monday. A new engineer, day one. Opens the "Getting Started" root, walks through subpages in order: "Day 1 setup → Tools → First PR → Codestyle → Deploy basics". Four hours without a single Slack question — everything is in the tree.

Tuesday. Production change — deploys now go through a new CI. A senior engineer opens "Deploy runbook", updates step 3, embeds a Loom video. The version is saved automatically — you can always roll back.

Wednesday. Architectural decision — a page "RFC · queue switch from Rabbit to Kafka" is created. A 12-message comment thread over 2 days, the decision is captured in a callout. The page becomes part of the Engineering tree.

Thursday. Quarterly review — Easylim sends 4 reminders to page owners: "check whether this is still accurate". Two update, one archives, one rewrites. Friday — a manager shares a public link to "Onboarding guide" with a client, who reads it without an account.

New-hire onboarding = walk 5–10 pages in order.
Process change = update one page, not announce in Slack to 30 people.
Quarterly review is the cheapest way to keep docs from dying.

breadcrumb · navigation

Workspace›

Marketing›

Brand›

Tone of voice

How we sound across product, marketing and support.

#brand#evergreen#owner: Mia

Розділ

When pages are the wrong tool — and what to use instead

If content lives less than a month (campaign brief, meeting minutes, PRD draft) — that's a document, not a page. Documents are flat, fast, easy to archive. Pages are for long-lived content.

Personal notes (my ideas, my planning, meeting prep) — those go in private notes. Pages are visible to the team by default — even when permissions can be locked down, the "private tree of one" format feels unnatural.

Visual thinking (mind map, user flow, architecture as a 2D diagram) — that's a whiteboard. A page can embed a whiteboard, but the page itself can't do 2D layout.

Active task execution — that's Kanban. If a page has a 50-item checklist, something went wrong. A 5-item checklist is fine; 50 items is a project and belongs in Kanban.