Confluence at scale: space architecture & permissions that don't collapse

Confluence is brilliant for the first 50 pages. By page 500 it's a swamp. By page 5,000 it's a search-result graveyard where the page that answers your question was last updated in 2019 by someone who left the company. The difference between the Confluence instances that survive and the ones that collapse is almost entirely about the space architecture and permissions model you set up in the first month.

This post is the architecture, permission model, templates, archiving strategy, and search hygiene we deploy on every Confluence instance we configure at Arventra.

Space-per-team vs space-per-product

The single most consequential decision. Both work, but they solve different problems:

Our recommendation for most organizations: hybrid. One space per team for internal/operational content (HR for HR, Engineering for engineering practices), plus one space per long-lived product or initiative for cross-functional knowledge. Avoid creating spaces for short-term projects — they accumulate forever; use pages-within-a-space instead.

The standard space set we recommend

• Company — handbook, policies, org chart, all-hands content. Read access for everyone.
• People — HR, benefits, hiring, performance. Restricted to HR + each employee's own pages.
• Engineering — practices, runbooks, ADRs. Read access for all, write for engineers.
• Product — strategy, roadmap, research. Read access for product + engineering + leadership.
• Per-product spaces — one per long-lived product, cross-functional documentation.
• Customers — account plans, QBRs, escalations. Restricted to GTM teams.
• Sandbox — drafts, experiments, things you're not sure where to put. Auto-archive monthly.

The permission trap (and how to avoid it)

Confluence permissions inherit from space → parent page → child page. The most common failure mode we see: an admin tightens one parent page, breaks inheritance for 200 children, and now half the company can't read the engineering handbook.

Our rules:

1. Set permissions at the space level. Never on individual pages unless you have a genuine reason that's documented in the page header.
2. Use groups, not individuals. "Engineering" not "alice@, bob@, carol@". Personnel changes shouldn't require admin work.
3. One restricted area per space, maximum. If you need more, the content probably belongs in its own space.
4. Audit page-level overrides quarterly. They accumulate silently and break inheritance.
5. Document who owns space permissions in the space description. When someone needs access, they know who to ask.

Page templates that get used

Templates only work if they're shorter than what people would write themselves. Five templates we ship on day one, ordered by adoption:

• Meeting notes — agenda, decisions, action items (with assignees). That's it. No "attendees" section nobody fills in.
• Decision record (ADR) — context, options considered, decision, consequences. Five sections, takes 10 minutes to fill out, durable for years.
• Runbook — when to use it, prerequisites, steps, escalation contact. Lives or dies on accuracy.
• Project brief — problem, goal, scope, milestones, owner. The "is this worth doing?" doc.
• Retrospective — what went well, what didn't, action items with owners and dates.

Templates we deliberately don't create: "Generic page", "Documentation", "Notes". If a template can't describe its purpose in one sentence, it's not a template — it's an empty page.

An archiving strategy that actually works

Pages don't expire. People do. Our archiving model:

• Every space has an "Archive" parent page. Outdated content moves there, doesn't get deleted. Searchable, but visually separated.
• Pages tagged with quarter labels (q1-2026, q2-2026) for time-bound content like OKRs, planning docs, and roadmap snapshots.
• A monthly Jira automation creates a "Review stale pages" ticket assigned to each space admin, listing pages not updated in 12 months. The admin decides: keep, update, or archive.
• Soft-delete via archive page first, hard-delete only after another 12 months. Hard-deletion is irreversible; the audit trail of "we tried to find this for 12 months and nobody objected" is worth keeping.
• Add a banner on archived pages linking to the current canonical version where applicable.

Search hygiene

Confluence search is only as good as the metadata you give it. The teams whose Confluence search "doesn't work" are usually the teams that never invested in any of the following:

• Page titles are search keywords. "Onboarding checklist — Engineering" beats "Onboarding". Include the noun a searcher would type.
• Use labels consistently. Agree on a small vocabulary per space (10–20 labels max) and stick to it. runbook, policy, adr, not free-text tagging.
• Pin the canonical page at the top of each space when there are obvious duplicates.
• Use page properties macros for structured metadata (owner, last reviewed, status) that the page-properties report can roll up.
• Front-load the answer. Search snippets show the first 150 characters. Don't bury the lede under a "Table of contents" macro.

The 30/60/90 review cadence

Documentation is a perishable asset. Our recommended review cadence:

• 30 days — owner skims, fixes anything obviously wrong (broken links, outdated screenshots).
• 60 days — owner reviews accuracy against current product/process.
• 90 days — full review. If still accurate, update the "last reviewed" property and move on. If not, update or archive.

For high-traffic pages (runbooks, onboarding docs), shorten this to 30/60/90 days. For low-traffic reference material, extend to 6 or 12 months.

Migration from another tool (Notion, Google Docs, SharePoint)

Three rules from our migration projects:

1. Don't migrate everything. If a page hasn't been opened in 12 months, it's archive material, not migration material. We typically migrate 20–40% of source content.
2. Re-architect during the migration, not after. The temptation to "just import then clean up" leads to permanent mess.
3. Use a phased cutover by space, not a big-bang. Engineering moves first, then Product, then GTM. Each space proves the model before the next.

Frequently asked questions

How many spaces is too many?

Above 50 spaces, navigation breaks down. Above 100, search becomes the only viable navigation. We aim for 15–30 spaces for most organizations under 500 people, scaling slowly from there.

Should we use Confluence whiteboards / databases?

Whiteboards yes for brainstorming and architecture diagrams. Databases yes for lightweight tracking (vendor lists, contact directories) but not as a Jira replacement — they're a useful complement, not a substitute.

How do we handle external collaborators?

Cloud Premium tier supports guest access — external users with read-only access to specific spaces, billed at a fraction of full users. For partner-facing content, this is the right answer. For customer-facing content, JSM's knowledge base is a better fit.

What's the difference between Confluence Cloud and Data Center for architecture?

Functionally similar for end users. Cloud has stronger search, native AI features (Atlassian Intelligence), and zero ops burden. Data Center wins for organizations with strict data-residency requirements or massive instances (10,000+ users) where Cloud Enterprise pricing doesn't pencil out.

How do we measure if Confluence is actually being used?

Three numbers: pages created per month per active user (target: 2+), pages viewed per active user per week (target: 10+), and search-to-page-view ratio (target: search drives 40%+ of traffic). Below these thresholds, content discoverability is broken.

Make your Confluence last

Confluence is a long-term investment. The teams that get value out of it three years in are the ones that set the architecture deliberately in the first month. If you'd like our team to design or rescue your Confluence setup, talk to our Atlassian consultants.