Organizing your knowledge base

Document360 uses a five-level hierarchy to structure all your documentation. Understanding this structure helps you plan and maintain a knowledge base that's easy to navigate

The hierarchy

Everything in Document360 follows this structure, from the outermost container down to individual content:

Each level serves a distinct purpose. Together they give you fine-grained control over how your content is organized, who can access it, and in what language it's presented.

Projects

A project is your top-level container. It holds everything - workspaces, content, users, settings, and configurations. When you sign in to Document360, your projects dashboard is the first thing you see. Each project is independent, with its own subscription, settings, and team members.

Workspaces

Inside a project, you can create one or more workspaces. Think of a workspace as a separate, self-contained knowledge base. Each workspace has its own content tree, its own URL, and can be set to different visibility levels — public, beta, or deprecated.

Workspaces are useful when you have different audiences or product lines that need distinct documentation. When you create a new project, a default workspace called v1 is created automatically.

Languages

Each workspace supports multiple languages, so you can deliver localized documentation to readers in their preferred language. You set a default language per workspace and add more as your audience grows.

Articles

Articles are the content your readers come for. They live inside categories and are the core building blocks of your knowledge base. You can create an article from scratch, from a template, or by using Eddy AI. Each article follows a draft-to-published workflow.

What this looks like in practice

Here's a simple example. Imagine a company called Acme that makes project management software. They have two audiences - everyday users and developers, who need completely different documentation.

Here's how Acme would structure their Document360 project:

Both workspaces live inside the same project, so Acme manages them from one place. Same subscription, same team, same settings. But to a reader, they feel like two completely different sites.

Workspace or category - which one do you need?

This is the question most new users get stuck on. Here's a simple rule:

✅ Use a new workspace when...

The audience is completely different and you'd never want both groups searching the same content. A developer and a customer support agent have nothing to search in common, So, separate workspaces keep the experience clean for each.

✅ Use a new category when...

It's the same audience, just a different topic. "Billing" and "Troubleshooting" are different topics, but they're both for the same user. So, they belong as categories inside the same workspace, not separate workspaces.

Best practices

These tips will keep your knowledge base clean as it grows:

Start with 3–5 top-level categories. You can always reorganize later. Document360 lets you drag and drop categories and articles at any time without breaking existing URLs.
Name categories based on what your readers are trying to accomplish, not your internal team's terminology. "Get started" lands better than "Onboarding flow."
Keep one idea per article. Focused articles are easier to find via search and simpler to keep up to date.
Use separate workspaces for genuinely different audiences. If your end users and your developers have very different needs, separate workspaces keep the experience clean for each group.
Avoid going deeper than two levels of subcategories. The deeper the nesting, the harder it is for readers to find their way - and for you to maintain it.

Documentation Index