Scroll Apps for Confluence
Backbone Issue Sync for Jira
AI-Powered Search for Scroll Viewport
About Us
Careers
Partner Program
Trust Center
Contact
Collaboration Hub
PDF Template Library
How to Manage Restrictions Across Multiple Confluence Pages
Atlassian champions the open by default approach to work, a mindset which Confluence mirrors by design. Part of working with a collaborative platform like Confluence means embracing an open way of working by leaving your Confluence pages open to your team for input and feedback.
But when your team needs to restrict content for whatever reason, this post will help demystify Confluence's permission scheme and show you how to apply more advanced document restrictions when content starts to span multiple pages.
Confluence Page Restrictions
Locking down your Confluence content is simple and straightforward. Use the restrictions icon at the top of each Confluence page to define the users or groups who have View and/or Edit access to the content:
If this list is empty, then everyone can view and edit the page. If there are users or groups listed, they represent the subset of people who are permitted to view and interact with the content of that page.
Since Confluence pages are open by default, you can think of this subset as the users who are 'permitted' to access the page, rather than a list of users whose access is restricted – an important distinction in the open by default mindset. Learn more about setting page restrictions in Atlassian's documentation.
How are Confluence Permissions Inherited?
So what happens when your content spans multiple pages in a page tree – a parent page and its children? It's important to know how the restrictions of the parent page will affect the child pages.
View restrictions are inherited by default, meaning if a user or group is restricted from viewing the parent page, they won't be able to see the children. If a teammate can't view the content of a page but is listed as having permissions to view or edit, it's likely due to the inherited view restrictions on the page:
But keep in mind that this inheritance differs when it comes to edit restrictions, which are not inherited by child pages in a page tree. So when the same edit restrictions of a parent page should also apply to the child pages, you need to individually set edit restrictions on all of these pages. If not, everyone will have permission to edit them.
Managing Restrictions Across Multiple Confluence Pages
For short single-page content, you might only be concerned about permissions a handful of times over the lifecycle of your content – if at all.
But a lot of teams handle content that can't be confined to a single page, as is the case with requirements documents, project documentation, proposals, and other documents that require a more defined structure in Confluence. Breaking up long content into a page tree will improve the readability of your content, speed up your team's feedback flow, help you publish changes faster, and give you better control over who can edit what.
But when you break up your content into multiple pages, knowing who has access to the entire page tree at any point in time can be a complex task if you're dealing with a large document. This is where Scroll Documents can help.
Bulk Updates to Page Restrictions with Scroll Documents
For a large page tree, you'll need an overview of who has access to it – who can read, contribute to, and alter its content.
Scroll Documents for Confluence enables you to define a page tree as one unit of content – a document – and perform more advanced document management functionality across these pages:
Save and compare versions
Apply workflow statuses
Export to PDF or Word
Send read requests to your team and manage confirmations in Confluence
Scroll Documents also provides an advanced restrictions UI to display which users or groups have access to the document, offering full visibility and control. Like page restrictions, you can easily add users and groups and individually define their access. All settings are shown in a single overview and you can update the restrictions across all the pages of the document in one go:
In case some pages in the document have inherited or individual restrictions set, you have the option to overwrite them here in order to give your team total access.
Define Read-Only Document Versions
Many teams need to create snapshots or record milestones of Confluence content in order to support their workflow. Some examples include saving a version of your product documentation to accompany a new release, or recording a paper trail of requirements as a part of your project documentation.
Scroll Documents' advanced restrictions provide some peace of mind that these Confluence documents are read-only when they need to be, which can be crucial for teams charged with maintaining the integrity of the versions or snapshots.
With the app, you can manually save versions of your documents at any point in time and then apply bulk permission updates to make these versions read-only with just a few clicks:
Try it Free
When Confluence's open by default approach isn't enough for your document management process, let Scroll Documents help. See how these advanced document restrictions can work for your team with a free 30-day evaluation license from the Atlassian Marketplace.
