How to Configure Confluence Pages, Permissions, and Space Settings for Enterprise Teams

Part A of this series covered Confluence's core architecture, licensing decisions, and the space design choices that determine whether a deployment scales or fragments. This second part moves from architecture to operation — the specific configuration decisions that IT managers and Confluence administrators make daily.

How pages are created, how drafts and version control work, how templates should be governed, how permissions cascade through groups and individuals, how space settings control the user experience, and how the platform integrates with the surrounding tool ecosystem. These are the decisions that separate a Confluence deployment that works from one that works well.

Page Creation: What Administrators Need to Know Before Users Do

The page editor in Confluence is intentionally accessible. Any user with edit permissions on a space can create a page by clicking the Create button in the top navigation or pressing C — the keyboard shortcut — from anywhere in the platform. The editor itself is familiar: a title field, a body area, and a formatting toolbar that covers standard text operations. The accessibility is by design, and it is largely an asset.

What administrators need to understand before rolling Confluence out to teams is the template system that operates alongside that page editor. When a user opens a new page for the first time, Confluence displays a template selection panel on the right side of the editor.

This panel contains Atlassian's full library of pre-built page templates: meeting notes, decision logs, product requirements documents, retrospectives, weekly status reports, technical documentation frameworks, and dozens more. These templates are not stylistic suggestions — they are structurally opinionated layouts that enforce consistency when adopted across a team.

Dan Lefebvre, an international Confluence consultant, describes the template value proposition precisely: templates "really just pre-populate a lot of that information, making it really fast to just come in and fill in the details." For IT managers, that value extends beyond individual page speed.

Teams using consistent templates produce pages that are structurally predictable, which makes search more effective, onboarding faster, and content auditing less labour-intensive. Teams not using templates produce pages that look and function differently depending on who created them — which is manageable at small scale and progressively harder to navigate as the organisation grows.

The template panel disappears as soon as a user starts typing in the page body, which confuses many first-time users. Typing signals to Confluence that the user has committed to a blank-canvas approach; the undo shortcut — Ctrl+Z on Windows, Cmd+Z on Mac — restores the panel. This is worth communicating explicitly in user onboarding documentation.

Template Governance: The Configuration Decision Most Deployments Skip

Confluence ships with a large template library. For a new user presented with sixty template options, the selection process creates enough friction that many default to a blank page — which defeats the purpose of having templates at all. Template governance is the administrative practice that resolves this, and it is among the highest-return configuration investments an administrator can make.

Within Space Settings, administrators can take two complementary actions on the template library. First, promoting specific templates places them at the top of the selection list, surfacing the most-used options immediately without requiring the user to scroll.

Second, disabling templates removes them from the list entirely, so the selection interface shows only templates relevant to that space's work. Lefebvre's guidance from real implementation experience is direct: "Go in there and clear out the templates that you're not going to use. It'll save you time having to scroll up and down."

The practical implementation approach is to identify the two or three templates that each team space will use most frequently — for an engineering team, that might be architecture decision records, sprint retrospectives, and incident post-mortems; for an HR team, it might be onboarding checklists, policy documentation, and meeting notes — promote those to the top, and disable everything else. The result is a template interface that guides users toward the right structure rather than overwhelming them with options they will never use.

This is a space-level setting, which means different spaces can have completely different template configurations.

An IT operations space can be configured for incident response templates; a product team space for roadmap and requirements templates; a legal space for contract and policy templates. Template governance at the space level is how administrators build a Confluence deployment that feels tailored to each team's work rather than generic to every team's work.

Drafts, Publishing, and Version Control: The Mechanism Administrators Must Explain

Confluence's approach to saving and publishing is one of the most important platform behaviours to understand and communicate, because misunderstanding it produces two common failure modes: users who accidentally publish unfinished content, and users who lose work they thought was being saved.

Confluence has no manual save button. The platform saves content automatically and continuously in the background from the moment a user begins editing. This is intentional and reliable — content is not lost to browser crashes, accidental tab closes, or network interruptions. The autosave operates regardless of whether the page is being created for the first time or edited after publication.

The distinction that matters is between saving and publishing. When a user creates a new page and closes the editor without pressing Publish, Confluence saves the content as a draft. Drafts are private to their creator — they do not appear in the space sidebar, they are not returned in search results for other users, and they are not visible to anyone with space access. The user can return to a draft through the Recent menu in the top navigation, selecting Drafts. The draft persists indefinitely until it is either published or deleted.

Once a page has been published at least once, the behaviour changes. Subsequent edits that are closed without republishing create an unpublished version that exists alongside the published page. Visitors to the page see the published version. The editing user sees an indicator that unpublished changes exist. The three-dot menu on the page provides a View Changes option that renders a diff between the published version and the unpublished changes — showing precisely what text has been added, removed, or modified. For complex pages, this diff view is essential for understanding the scope of changes before committing to a publish.

If unpublished changes are no longer wanted, Revert to Last Published Version restores the page to its last published state cleanly. There is no recovery path from a revert — the unpublished changes are discarded permanently — but the published content is fully intact.

For administrators configuring a new deployment, these mechanics are worth documenting explicitly in user onboarding materials. The "where did my changes go?" question and the "did everyone see my unfinished draft?" concern are both rooted in misunderstanding this system. Resolving them proactively reduces support overhead significantly.

Page Editing: The Capabilities That Produce Professional Confluence Content

Understanding what the page editor can do beyond basic text formatting is what separates teams that use Confluence as a word processor from teams that use it as a knowledge management platform.

Column layout is the most immediately useful structural capability. Confluence pages default to a single-column layout, which works for linear text but creates unwieldy pages for content that is conceptually parallel — two processes being compared, navigational content alongside body content, data summaries alongside their explanations. The column layout tool creates two-column, three-column, sidebar-left, sidebar-right, or three-column-with-sidebars layouts, and content within those layouts can be rearranged by drag and drop. Pages designed with deliberate column structure are significantly easier to scan than pages where everything stacks vertically.

Tables in Confluence are functionally richer than they appear. Individual columns can be resized, tables can be extended to full page width when data demands it, header rows and header columns can be toggled independently, and the overall table can be wider than the page's fixed layout — useful when displaying matrices or structured data that requires horizontal space. For IT managers maintaining permissions matrices, system inventories, or infrastructure documentation in Confluence, understanding table configuration is practical rather than cosmetic.

The macro system is where Confluence's integration value becomes operationally significant. From the formatting toolbar, users can insert macros that pull live data from connected systems into the page. The Jira Issues macro is the most strategically important for organisations running both products — it displays a live, filtered view of Jira issues directly within a Confluence page, updating automatically as issue status changes in Jira. An architecture decision record page, for example, can embed a live view of the Jira epics it informed. An incident post-mortem page can embed the Jira issues that tracked the resolution work. The Confluence page becomes a context layer over the Jira data, not a static copy of it.

The Table of Contents macro provides a different type of value — navigational rather than integrative. It reads the heading structure of a page and generates a linked contents section automatically. For long technical documentation pages with multiple sections, a Table of Contents macro at the top of the page transforms navigation without any manual linking. It updates itself whenever headings change, removing a maintenance step that is easy to forget.

Page width — fixed or full — is a toggle in the editor toolbar. Fixed width creates reading-optimised line lengths suited to text-heavy content. Full width suits data-heavy content where tables, diagrams, or wide layouts need more horizontal space. The choice is page-specific; administrators can set it for any page and users with edit permissions can change it.

Space Settings: The Administrative Surface That Controls the User Experience

Space Settings is the configuration layer that determines how a space functions for every user who accesses it. It is visible only to users with administrative permissions for that space — a deliberately restricted surface, because the decisions made here affect everyone.

Manage Space contains the core identity settings for a space: its display name, its URL key, its logo, and its home page. The URL key is assigned at space creation and used in all URLs for that space's pages. Changing the key after pages have been shared externally will break existing links — a significant operational consideration for spaces whose content is referenced from external systems, email communications, or other Atlassian products. Treat the space key as permanent unless you have a controlled process for updating references.

The home page for a space is where users land when they navigate to the space directly. It defaults to the Overview page created automatically with the space, but any page within the space can be designated as the home page through Edit Space Details. Lefebvre's recommendation from consulting practice is worth taking seriously: "Use the home page for each space as a way of helping your team be more productive. Whether that's pulling in Jira issues that they need to see, whether that's helping give some tips and tricks for how they can navigate the space." Home pages designed with navigational intent — surfacing the space's most important pages, embedding live data from Jira, providing orientation for new team members — deliver consistent value every time someone arrives at the space. Home pages left at the default empty Overview provide none.

The sidebar editor within Space Settings controls which navigation elements appear in the space sidebar. The Overview entry and the Blog entry can be individually enabled or disabled. Teams not using Confluence's blog feature should disable it — it takes up navigational real estate and creates a visible option that generates questions about its purpose. The rule is simple: if a navigation element is not serving your team's workflow, disable it.

Hidden pages and undefined pages, surfaced in Manage Pages within Space Settings, are two content states that require periodic administrative attention. A hidden page is a page that exists but has no links pointing to it and does not appear in the space sidebar — effectively stranded content that cannot be reached through normal navigation. Hidden pages accumulate when pages are reorganised without updating links, when a page's parent is changed without considering its navigational context, or when content is moved between spaces without appropriate cross-linking. Regular audits of the hidden pages list prevent knowledge from disappearing into navigational dead ends.

Undefined pages are the inverse: pages that have been linked to from within Confluence but have not yet been created. They appear as placeholders in the page hierarchy. Creating an undefined page intentionally — linking to a page you intend to write before writing it — is a legitimate content planning practice. Undefined pages accumulating without being addressed become a maintenance debt that signals to users that the space is not being actively managed.

Permission Architecture: Building Access Control That Scales

Confluence's permission system operates at three levels, and understanding how those levels interact is fundamental to building access control that serves the organisation without creating administrative overhead.

The highest level is the overall platform permissions, configured by the Confluence administrator in the global settings. This level controls who can log in, who can create spaces, and what default access new users receive. Below that are space-level permissions, configured by space administrators within each space's Space Permissions settings. Below that are page-level restrictions, applied by page editors to individual pages within a space.

Space permissions are structured around groups and individual users. Atlassian pre-configures two groups in every Confluence installation: Confluence Administrators (overall platform administrators) and Confluence Users (all users with platform access). Additional groups can be created by administrators and assigned to spaces, making it possible to grant or restrict access to an entire department, project team, or role without manually managing each user individually. For organisations with more than twenty or thirty Confluence users, group-based permission management is not optional — it is the only approach that remains maintainable at scale.

The interaction between group permissions and individual user permissions has a critical nuance that generates support tickets in every Confluence deployment: individual user permissions override group permissions in both directions. If a user has been explicitly granted access to a space as an individual user, removing their group's access to that space will not remove their personal access. Lefebvre makes this explicit: "If you give an individual user permission, that will override whether or not they're in a group or not." Administrators who change group permissions and assume they have changed all access are wrong whenever individual grants exist. Auditing individual user permissions explicitly after group permission changes is a necessary operational practice.

Anonymous access — making space content visible to anyone on the internet without requiring a Confluence login — is the mechanism by which organisations publish public-facing documentation, knowledge bases, and change logs through Confluence. It is disabled by default, and Lefebvre's guidance reflects standard security practice: leave anonymous access disabled "unless there is a very specific reason to turn it on." The default should be authentication; exceptions should require explicit justification and regular review.

Content Lifecycle: Archive, Delete, Export, and What Cannot Be Undone

Confluence's content lifecycle has asymmetric consequences, and administrators need to understand which actions are reversible and which are not.

Deleting a page sends it to the space's Trash, from which it can be recovered. The trash acts as a standard recycle bin: content is retained, recoverable, and visible to administrators through the Trash section in Space Settings until explicitly purged. Page deletion is therefore a low-risk action.

Deleting a space is a different matter entirely. Lefebvre is direct: "Once you delete the space, there's no way to bring any of that information back once it's deleted." Space deletion is permanent and immediate — there is no space-level trash, no recovery path, and no undo. Before any space is deleted, the content should be exported or migrated if it has any potential future value. Governance processes for space deletion should require administrator review and explicit sign-off, not just the technical capability to click the delete button.

Archiving offers a middle path. Archived pages are hidden from primary navigation — they do not appear in the sidebar, they are not surfaced in default browsing — but they continue to exist within the space and remain searchable with appropriate permissions. Archiving is the correct choice for content that is no longer actively maintained but may have reference or historical value: superseded process documentation, previous-year planning material, system documentation for retired infrastructure. Lefebvre's recommendation is pragmatic: if you are not certain content should be deleted, archive it.

Exporting spaces allows administrators to create complete archives in various formats, supporting backup, migration, and offline reference. For teams planning a migration from Confluence Server to Cloud or Data Center, the export tool is the primary data transfer mechanism. Export quality depends on the format chosen — some formats preserve more formatting and page structure than others — and testing the export process before executing a production migration is essential.

Integrations: Connecting Confluence to the Tools Your Team Already Uses

Confluence's value as a knowledge management platform increases substantially when it is connected to the other systems your organisation uses for project tracking, communication, and development.

The Atlassian application link framework allows Confluence spaces to be formally connected to Jira projects. This connection does more than enable Jira macros in Confluence pages — it adds a navigational link in Jira's project sidebar that takes team members directly from their Jira project to the relevant Confluence space. For teams working across both products, this bidirectional navigation reduces the friction of context-switching and reinforces the intended relationship between project tracking in Jira and knowledge management in Confluence.

Slack notifications, available through Space Settings under Integrations, route Confluence activity events — page creation, page updates, comments — into designated Slack channels. For teams operating primarily in Slack, this integration surfaces knowledge base updates where team members are already paying attention, reducing the discovery gap between content creation and content consumption. The configuration is at the space level, which means different Confluence spaces can route notifications to different Slack channels — engineering updates to an engineering channel, HR policy updates to a general announcements channel, and so on.

RSS feeds, also available through Integrations, allow external systems or RSS clients to subscribe to space activity. For organisations publishing externally-facing documentation through Confluence, RSS provides a programmatic notification mechanism for downstream consumers of that content.

The Implementation Gap That Onpointserv Closes

The consistent pattern across Confluence deployments that underperform is not a technology failure — it is an implementation gap. The platform works. What fails is the absence of deliberate upfront decisions: space architecture designed before spaces were created, permissions structured before users were onboarded, templates curated before content creation began, governance frameworks in place before the first team started publishing. The decisions covered across this two-part guide are not optional configuration steps; they are the conditions that determine whether Confluence becomes a trusted operational asset or an expensive shared drive that nobody fully trusts.

Onpointserv's project management and team tools implementation practice provides structured deployment support across the full implementation lifecycle: Atlassian licence selection and procurement, Confluence space architecture design, Jira-Confluence integration configuration, permission framework development, template governance, user onboarding, and post-deployment governance review. For organisations inheriting unstructured Confluence deployments, we provide remediation engagements that restore navigability and user confidence without requiring a platform rebuild.

If your organisation is planning a Confluence deployment, migrating from Server to Cloud, or managing a deployment that has grown difficult to govern, contact Onpointserv to discuss implementation support.

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