Confluence for Beginners: The Complete IT Manager's Guide to Spaces, Licences, and Core Architecture

When an organisation decides to implement Confluence, the decision rarely lands with a project manager or a department head. It lands with the IT manager or system administrator who has to make it work — who has to select the right licence, design the space architecture, configure permissions, and then somehow get a hundred different people using the same platform consistently.

This guide exists for that person. It covers the foundational decisions that determine whether a Confluence deployment becomes a scalable knowledge management system or a sprawling repository that teams gradually stop trusting.

This is Part A of Onpointserv's two-part Confluence implementation series. Part A covers Confluence's core architecture, licensing decisions, and foundational concepts. Part B covers operational configuration: pages, drafts, version control, space settings, macros, and the permission structures that govern access at scale.

What Confluence Is — and What It Is Not

Confluence is a wiki application: software designed specifically for collaborative content creation and editing through a standard web browser, with no client installation required for end users. Atlassian, the Sydney-based enterprise software company also responsible for Jira, developed Confluence as the knowledge management layer of its product suite.

If Jira tracks what your organisation is doing and what needs doing next, Confluence documents why things are done the way they are, how processes work, what standards apply, and what your organisation has learned.

That framing matters because the most common implementation mistake IT managers make is deploying Confluence as a general-purpose file store — effectively replacing a shared drive rather than building a knowledge base. Confluence supports file attachments, but it is not optimised for binary file storage in the way Dropbox, SharePoint, or Google Drive is.

Its value lies in structured, searchable, collaboratively maintained information: process documentation, technical standards, onboarding guides, system change logs, API references, architecture decisions, and the accumulated institutional knowledge that otherwise lives in senior employees' heads and disappears when they leave.

Dan Lefebvre, a Confluence process consultant with international deployment experience, describes Confluence as "a digital brain for your organisation, a place where things can be stored" — distinguishing it explicitly from file storage by emphasising that the unit of value is information, not files. That distinction should inform every architecture decision you make during implementation.

Confluence vs Jira: Resolving the Integration Question Before Deployment

IT managers implementing Confluence in an Atlassian environment face an early architectural question: how tightly should Confluence and Jira be integrated, and what content belongs in each system? The boundary is not always obvious, and blurring it creates duplication, confusion, and maintenance overhead.

Jira is optimised for tracking active work: issues, sprints, epics, bugs, feature requests, project status, and workflow states. Its data model is transactional — items move through statuses, are assigned, resolved, and closed. Confluence is optimised for reference knowledge: content that is created once and updated periodically, that provides context for decisions rather than tracking decisions themselves. Its data model is documentary — pages accumulate content, are revised collaboratively, and are organised hierarchically.

A practical boundary: if your development team is building version 3.0 of a product, the sprint boards, bug reports, and task assignments live in Jira. The architecture decision records, coding standards, API documentation, and release change logs live in Confluence. When version 3.0 ships, Jira closes out its issues; Confluence updates its documentation.

The two systems reference each other through Atlassian's native integration — Jira macros in Confluence pages pull live issue data without manual synchronisation — but they do not duplicate each other.

For teams not running Jira, Confluence operates independently. Licences for Confluence and Jira are separate; having one does not require the other. For teams running both, the integration is the most strategically significant configuration decision in the deployment.

Licensing Architecture: Choosing Between Cloud, Data Center, and the End of Server

Before any technical configuration begins, your organisation needs to select its Confluence licence. This decision shapes everything downstream — how updates are managed, where data resides, what administrative overhead your team carries, and how quickly new Atlassian features reach your users.

Confluence Cloud is the SaaS version. Atlassian manages infrastructure, maintenance, security patching, and version upgrades. Your organisation pays a per-user monthly subscription and Atlassian handles the operational overhead. The practical implications for IT managers are significant: Cloud instances are always running the latest Confluence version, because Atlassian rolls out updates automatically. There is no version migration project, no infrastructure maintenance schedule, and no risk of running a version three years behind current because an upgrade was perpetually deprioritised. For organisations without strong data residency requirements or reasons to maintain Confluence on their own infrastructure, Cloud eliminates an entire category of operational overhead.

Confluence Data Center is the self-hosted enterprise option. It is installed and maintained on your organisation's infrastructure — your data centre, your cloud provider, your responsibility. Data Center is appropriate for organisations with strict data sovereignty requirements, regulated industries where data residency is a legal obligation, or enterprise environments where the level of control over infrastructure is non-negotiable. It receives all new Atlassian features, unlike Server, and supports clustering for high availability.

Confluence Server is being retired. Atlassian is working through an end-of-life process for Server, and as of this writing, new features from Atlassian are no longer being developed for it — all product investment flows to Cloud and Data Center. If your organisation is running Confluence Server, this is not a theoretical future concern. It is an active risk management issue. Any Confluence deployment on Server needs a documented migration path to Data Center or Cloud, and that migration planning should be underway now, not at the point where Server reaches its support deadline.

For organisations evaluating Confluence for the first time, Cloud is the default recommendation unless regulatory requirements or existing infrastructure commitments argue otherwise. For IT managers inheriting a Server installation, the first decision to make is the migration target and timeline.

Core Architecture: Pages, Macros, and Spaces

Confluence's information model rests on three concepts that administrators need to understand precisely, because their misuse at the architecture level creates problems that are expensive to fix later.

Pages are the foundational unit of content in Confluence. Everything your organisation stores in Confluence — text, images, tables, file attachments, embedded data from integrated systems — lives on pages. Pages exist in hierarchies: a page can have child pages, which can have their own children, creating a tree structure that reflects the logical organisation of a team's knowledge. Page hierarchy is not just navigational; it affects how content is discovered, how permissions cascade, and how spaces are ultimately maintained. Flat page structures are easier to create and harder to navigate. Deep hierarchical structures are more powerful but require deliberate design.

Macros are Confluence's mechanism for embedding dynamic content on pages. The practical value for IT managers and admins is substantial. A Jira Issues macro on a Confluence page displays live data from a connected Jira project — updated automatically whenever issue status changes in Jira, without any manual refresh or copy-paste. A Table of Contents macro reads a page's heading structure and generates a linked navigation section automatically, updating itself whenever headings change. Macros transform static documentation into living reference material, and understanding them is what separates teams that use Confluence as a word processor from teams that use it as an operational intelligence layer.

Spaces are the organisational containers within which pages live. Lefebvre uses a filing cabinet analogy that maps cleanly to the administrative reality: "If we think of Confluence as the overall filing cabinet, then we can think of each drawer in that filing cabinet as a space." Each space has its own permissions structure, its own navigational sidebar, its own template configuration, and its own administrative ownership. Spaces are the primary unit of access control in Confluence, and the space architecture your team designs before deployment determines how manageable the platform is at scale.

Space Architecture: The Design Decision That Scales or Breaks Your Deployment

The space architecture question — how many spaces, organised around what principle, owned by whom — is the most consequential implementation decision an IT manager makes. There is no universally correct answer, but there are patterns that consistently produce manageable deployments and patterns that consistently produce sprawl.

Confluence recognises two types of spaces with meaningfully different characteristics.

Personal spaces are created and owned by individual users. Every Confluence user can create their own personal space without requiring administrator approval, because personal spaces do not require overall administrative permissions to create. They serve as individual staging areas, working notes repositories, and sandboxes — places where content can be drafted before it is ready to be published into a shared team space. Personal spaces can be made completely private, visible to selected individuals, or open to the whole organisation. Their administrative responsibility rests with the individual user, not with the Confluence administrator.

For IT managers, personal spaces represent a low-governance, high-autonomy area of the platform. The tradeoff is worth accepting: allowing individuals to manage their own spaces reduces administrative overhead and encourages content creation without bureaucratic friction. The risk is that personal spaces become permanent homes for content that should be in a team space — information accessible only to one person when the whole team needs it. Governance guidelines that define what content belongs in personal spaces versus team spaces prevent this drift.

Team spaces require overall Confluence administrative permissions to create. They are intended for organisational and departmental use — the shared knowledge of an engineering team, the operational documentation of an HR department, the technical standards maintained by a platform team. Team spaces are where the organisation's institutional knowledge lives, and their design should reflect the actual structure of how your teams create and consume information.

The most common space architecture mistakes are over-segmentation and under-segmentation. Over-segmented deployments create one space per project, resulting in dozens of low-content spaces that fragment related information and make search less effective. Under-segmented deployments create one space per department and dump everything into it, resulting in spaces with hundreds of pages and no coherent organisation. The appropriate granularity is usually somewhere between these extremes — spaces organised around durable teams, products, or domains rather than ephemeral projects or rigid org-chart departments.

Lefebvre draws the key distinction in terms of intent: "Team spaces are intended to be used by the whole organisation or by teams in our organisation working together. Personal spaces are really intended to be used individually." That intent should be preserved in your governance documentation from day one.

Navigating the Confluence Interface: An Administrator's Orientation

The Confluence interface underwent a significant structural change in 2020, when Atlassian migrated navigation from the left sidebar to the top bar. Administrators managing users on older versions of Data Center or Server will recognise the left-sidebar layout; Cloud instances and updated Data Center instances use the top-bar navigation. If your organisation's Confluence users are confused by interface differences across teams, the version and licence discrepancy is the cause.

The top navigation bar provides access to the core administrative and navigational functions. The app switcher in the top left connects to other Atlassian products — Jira, Bitbucket, Trello, and any others your organisation has licensed. The Spaces dropdown surfaces recently visited spaces and provides a route to all spaces the logged-in user can access. The People section manages user discovery and, for administrators, user invitations — noting that adding users to a Cloud instance adjusts the billing headcount, which requires administrator-level authorisation in most licensing models.

The Search function — triggered by the forward slash shortcut — is scope-limited by permissions. Users can only find content in spaces to which they have access. This is an important trust signal for organisations concerned about information security: Confluence search does not surface restricted content to unauthorised users, and testing this explicitly during deployment verification is good practice.

The administrative gear icon in the top right is visible only to users with overall Confluence administrator permissions. This is where platform-level configuration lives: user management, space management, global permissions, application links to Jira and other Atlassian products, and look-and-feel customisation. Space-level settings are separate and accessed through the individual space's sidebar — a distinction that new administrators sometimes conflate.

Why Implementation Decisions Made Today Shape Every Future Upgrade

The architectural decisions made during initial Confluence deployment — licence selection, space design, permission frameworks, template governance — create structural patterns that propagate forward through every upgrade, every user addition, and every team expansion. They are significantly more expensive to reverse after the fact than to get right upfront.

Organisations that invest in deliberate implementation — defining space architecture before creating spaces, establishing permission governance before onboarding users, curating templates before encouraging content creation — consistently report higher adoption rates, lower administrative overhead, and greater user trust in the information Confluence contains. Those that deploy first and structure later consistently report the opposite: a platform full of content nobody trusts because nobody knows whether it is current, findable, or maintained.

Onpointserv's project management and team tools implementation practice provides the structured implementation support that closes this gap — from licence selection and space architecture design through to user onboarding, governance framework development, and Jira integration configuration. For organisations inheriting an existing Confluence deployment that has grown difficult to manage, we also provide structured remediation engagements that restore navigability and user confidence without requiring a rebuild from scratch.

Part B of this series covers the operational layer: creating and managing pages at production quality, configuring space settings for scale, building permission structures that protect without impeding, managing drafts and version control, and using macros to build the dynamic, integrated pages that deliver Confluence's full value.

About Onpointserv Onpointserv delivers project management and team tools implementation services to organisations building on Atlassian's product suite. Our practice covers Confluence deployment architecture, Jira configuration, Atlassian Cloud migrations, and the governance frameworks that make knowledge management tools work at scale.