Confluence structure that people can find things in
Nobody complains about the information architecture. They complain that they cannot find the thing, which is the same complaint.
Confluence rarely fails because the hierarchy is wrong. It fails because there are three plausible places a document could live, nobody agreed which one, and search returns four versions of the same page with no way to tell which is current. The fixes are unglamorous: fewer spaces, one hierarchy rather than two, labels doing the cross-cutting work, templates carrying the labels automatically, and an archiving habit that somebody actually owns.
The complaint is always search, and the cause is usually structure
Atlassian defines a space plainly: a container where you and your team create, store and collaborate on work related to a team, shared project or initiative, and the guidance is to create as many as you need. That is reasonable advice for a product team and dangerous advice for an agency, because an agency generates a new candidate space every time it signs anything.
The failure that follows is predictable. Somebody searches for the ACME measurement plan, gets six results across three spaces, and picks the one that looks most complete. It is from March. The current one is in a different space because a different person started it during a different engagement, and neither page says which is which.
That is not a search problem. It is a structure problem presenting as a search problem, and no amount of better queries fixes it. The two decisions that cause it are how many spaces exist and whether anything is ever archived, and both are made by default rather than deliberately.
This article covers Confluence Cloud. The Data Center product organises the same concepts differently in places, and folders in particular are a Cloud feature, so if you are on Data Center, read the equivalent page for your deployment rather than assuming the behaviour carries across.
One space per client, or one per engagement
| Structure | Works when | Fails when |
|---|---|---|
| One space per client | The same people work across every engagement for that client | One engagement has a genuinely different audience, such as the client's own staff |
| One space per engagement | Engagements are large, long, and have distinct teams | You sign twelve engagements a year and nobody can find last year's decisions |
| One space per function, split by client inside | The agency's internal method matters more than the client boundary | A client is given access, because access is granted at the space level |
This is the same decision as the Jira project shape question, and for the same reasons it wants the same answer. The cost of too few spaces is a crowded content tree. The cost of too many is that nobody can tell you where anything lives, which is unrecoverable without a migration.
The rule I use is one space per client, with engagements as branches of the content tree inside it, and a separate space only when the audience genuinely differs. A client who is allowed into Confluence is a different audience. A subcontractor who should see one workstream is a different audience. A second project for the same people is not.
The equivalent decision on the tracker side, and the way its costs escalate over a year, is in setting up a Jira project for a client engagement. Keeping the two structures parallel is worth more than optimising either one, because the person looking for a document usually starts from the work item.
Folders and parent pages are not the same tool
Confluence Cloud gives you two ways to nest content and they behave differently. Atlassian's framing is that a parent item is a container that carries its own content and context, while a folder is a simple container with no information built into it. Use a parent page when arriving at the container should tell you something. Use a folder when it should not.
That page carries one behaviour worth knowing before you rely on folders. Deleting a folder does not delete its contents; they move up a level in the content tree. Any restrictions those pages inherited from the folder are removed at the same time, leaving only their own restrictions and whatever they inherit from the new parent. So a folder is not a security boundary you can trust to survive a tidy-up.
Two smaller mechanics. Folders must be created from the content tree, not from the global create button, which surprises people who go looking for it. And folders can be turned on or off per space in Space settings under Features, but not at the site level, so if you want them off everywhere that is a per-space job.
For the reading side of the same structure, the content tree macro renders a hierarchical list starting from a chosen root, so an engagement overview page can carry its own live index rather than a hand-maintained list of links that goes stale within a month.
Labels do the job a hierarchy cannot
Every project document belongs to at least two categories: where it sits in the engagement, and what kind of document it is. A tree can only express one of those, and the standard mistake is trying to express both by nesting deeper.
Labels are the second axis. Atlassian describes them as key words added to pages and attachments to make content easier to group and find, and clicking one on a page finds everything else carrying it. So the tree carries the client and the engagement, and labels carry the type: meeting-notes, decision, spec, runbook.
Two constraints shape how you name them. Labels are lower case only and do not accept spaces; a typed space is converted to a hyphen automatically. That is a small mercy, because it means the naming convention is partly enforced for you. What is not enforced is consistency, so agree six labels rather than sixty, and write them down somewhere that new people read.
The detail that makes labels stick is on the same page: labels added to a template are applied automatically to every page created from it. That converts labelling from a discipline into a default, which is the only version that survives a busy quarter.
Templates are the only durable way to enforce a shape
A documented standard nobody follows is not a standard. A template is a standard that arrives pre-filled, and it is the single highest-return thing to build in a client space.
In Confluence Cloud, only space administrators can create or edit space templates, which is a constraint worth planning for rather than discovering. Templates support variables, which prompt the author for values when the page is created, placeholder text, and the labels described above. They do not support images or attachments, so a template cannot carry a diagram.
Four templates cover most agency work: a meeting note with decisions and actions separated, a decision record, a status update matching whatever format the client already reads, and an engagement overview that becomes the space's landing page. That is a morning's work and it is the difference between a space with a shape and a space with three hundred pages in it.
The decision record is the one that pays back years later. On a clinical research programme, the value of 159 work items with acceptance criteria was not the count, it was that the reasoning stayed readable after the people who wrote it had moved on. The same is true of a page that records what was decided and what was rejected. The engagement overview page is also the natural home for the scope and the boundaries, and what belongs on it is covered in a project charter someone actually reads.
Permissions, and the plan cliff underneath them
Every space has its own permissions, granted and revoked by a space admin, and the person who creates a space is automatically an admin of it. Atlassian's space permissions reference lists them individually: View, Add, Delete, Delete Own, Restrictions and Admin, with Add and Delete assignable per content type.
Two facts from that page change what is possible. Space permissions are not customisable on the Free plan, and neither are page restrictions, so a Free site cannot separate a client's view from everything else no matter how carefully you arrange the tree. And if somebody removes the last admin from a space, recovery requires a person holding the Confluence Administrator global permission, which is worth knowing before it happens on a Friday.
Confluence is also open by default. General access means everybody with view access to the space, or to a restricted parent, and that is the correct default for an internal wiki and the wrong assumption to carry into a space a client can enter. The same four-control mental model that applies to the tracker applies here, and it is set out in letting a client into Jira without letting them into everything.
The equivalent question for the files that never make it into Confluence at all, which in most agencies is most of them, is handled in SharePoint governance for client files. Documents and deliverables usually live in two systems, and pretending otherwise is how a client ends up with an out-of-date copy of something.
Archiving is the maintenance nobody schedules
A space nobody prunes becomes a space nobody trusts, and the moment people stop trusting it they start keeping their own copies, which is the failure state you cannot come back from.
Archiving is the tool for this and it is less destructive than people assume. Atlassian documents that archiving removes an item from the content tree and from quick search without deleting it. Existing links still work and are marked with an Archived lozenge so a reader knows what they have opened. Editing, commenting and liking are disabled, which preserves the state of the page as it was. An advanced search can still include archived content when somebody genuinely needs it.
Two practical notes from that page. Each space has its own archive and there is no site-level archive, so archived content stays with its space. And restrictions still apply to archived items, which means a page a client could not see stays invisible to them in the archive too.
Attach the archiving to something that already happens rather than to a reminder. When an engagement closes, the closedown step is: update the overview page with where things ended, archive the pages that described work in flight, and leave the decisions and the handover. Ten minutes, once, and the space stays readable. That closedown discipline is the same one that keeps the tracker usable in month eighteen, and it is one of the reasons documentation structure tends to be an early deliverable in a fractional technical project management engagement rather than something anybody gets to later.