A unified way to share and manage access to content in Confluence

[#1]

Hello Atlassian Admins,

I couldn’t be more excited to announce that starting today, customers will begin to see enhancements and updates to how you manage sharing and access across all content types in Confluence Cloud.

Sharing should be simple, intuitive, and stress-free. These updates to sharing put everything – content restrictions, access management, and sharing options – into a single, streamlined flow. Check it out!

Note: If you don’t see the updates to sharing and managing access yet, don’t worry! You should see it in the coming days or weeks as we roll it out across all Confluence sites.

What to expect 

A single place to share and manage access

Prior to these changes rolling out, you had to go to two separate places to manage content restrictions and notify your collaborators.

• The padlock icon is where content restrictions and access were managed

• The Share button is where notifications were sent from

Now, from a single Share button and through a unified flow, you can modify content restrictions, notify users and groups when you give them access, and easily share content. Because we know that links to your content (Page, Whiteboard, Database) are frequently shared, we also added the button for ‘copy link’ to the Share button too!

In addition, the features you loved from the old experience, like inspecting permissions to understand if someone could access your content, sharing to Slack, and turning content into public links, are also now all in one place.

Quickly identify who has access to your content

In the General access section, easily identify whether the content is open to anyone in the space or restricted to specific people.

Smart suggestions for who to share with

We’re making it easier to share content with your frequent collaborators by presenting quick-add buttons. When you select one of these quick-add people, they’ll be added directly to the user field in one click. No need to search for them.

Expandable specific access

For a more streamlined experience, we’ve collapsed the list of users with specific access into a summary statement. Simply expand to see the full detailed list.

Personalized share notifications

Choose whether to notify newly added people. You can notify with a standard system message or include a custom message. Alternatively, you can uncheck the box to simply grant access quietly without notifying anyone. The choice is yours!

Warnings when sharing with groups prevent accidental oversharing

It’s more efficient to use groups to manage access at scale. Now we’ve given you more control over notifications when managing access with groups. When sharing with a group, you'll get a warning before notifying everyone in that group to protect you against accidentally notifying too many people.

Better awareness when there are access problems (and quick fixes to them!)

Now, when you try to share with someone who, at the end of it, won’t have the intended access due to space access or parent content restrictions, you’ll get a message alerting you to the issue. And, if you’re empowered to grant access to the space or parent content, you’ll be able to do so with one click to prevent an access problem from happening.

For example, say you’re sharing with a colleague who is restricted from viewing the parent content item. Because they can’t view the parent, they also can’t view the child, even though they’re not explicitly restricted from viewing the child.

What’s not changing

Rest assured, no access is changing as a result of these updates. Restricted content stays restricted, open content stays open, and individual access remains as per your current settings.

What’s coming next

We’re just getting started with improvements sharing and access in Confluence!

Coming soon:

• New ways to request access to content.

• A home for managing content access requests. No more chasing them down in email or in-app notifications.

• Teams in Share and other places you manage access, alongside users and groups.

• Better warning messaging when sharing with groups, so you know exactly how many people will be notified.

• More flexible Specific access. Adding someone specific? They’ll be added to the Specific access list. Period. No matter the access state.

Learn more about these updates

Knowing where to manage access and share is important to all Confluence users. To make sure everyone knows about these updates, we’ve incorporated in-product messaging to guide users through the changes.

You can also explore our documentation to see all of the changes to sharing in Confluence

• Manage permissions at the content level
• Change who can find content and what they can do with it
• Share Confluence content
• Troubleshoot access problems to content

As always, let us know what you think of the new unified sharing experience in the comments below!

- Marie and the Confluence Permissions team

[Darryl Lee]

@Marie Casabonne thanks for the news.

I wonder if you can clarify an old question and let us know how these new changes may affect things.

There are currently two "short links" that Confluence provides, as @Mark de Bont asked back in 2023, but for which nobody from Atlassian proper ever answered:

• Two different types of tiny links? which to use? 

As @Chris Kite later clarified the old "Links" button had the same "Tiny Link" that is on the Page Information page in this format:

<mysite>.atlassian.net/wiki/x/XXXX 

But the new Share button includes a Link that changes every time you hit it:

<mysite>.atlassian.net/l/cp/XXXX

At the time, @Nic Brough -Adaptavist-  theorized that the latter Share links might be temporary, and that they might be revocable or expire? But I've never seen such a feature.

At any rate, would love to hear what you know about that.

And I'm wondering what type of "Short Link" will the new Unified Sharing use? I assume (HOPE) that all old links will still persist, since those could live in many places outside of Confluence (emails/Word/Powerpoint/PDFs).

SIDENOTE: I recently was asked to write an automation to get # Comments and # Unique Viewers for Confluence pages that were linked in Jira tickets in a URL field. UNFORTUNATELY many of these links were entered as Tiny or Share Links.

The problem is that the API endpoints to get total comments or unique viewers require a PageID. And there is no API to reverse-engineer a PageID from a Tiny or Share Link. So I have to take the fairly sketchy step of making a Web Request to the Tiny or Share Link and trying to scrape the contents (using the match text function) of the page to find the PageID.

Sometimes Web Requests follows the redirect, sometimes it doesn't. So... about 1/2 the time I fail to get the PageID because the content that I'm trying to scrape isn't consistent. Fun times.

But hey, congrats on the new feature!

[Steve Rhodes]

And how exactly does this compare to the feature we have now? Am I right in that its a merger of the restrictions and sharing dialogue plus some tidying up and the following three features?

Smart suggestions
Personalised share notifications
Warning when sharing with groups

[Amy Carey]

I see the notification checkbox defaults to on/yes. Is there a way to globally turn off the notification checkbox so it is not checked when using the Share button? Have the notification checkbox default to off/no?

[Don McFall]

Why was this rolled out before sharing with teams was included?  We have users that have been using that feature and now, unexpectedly, can no longer do so.  This is a reduction in functionality for them.

[Shelley Duncan]

This is a nasty way of merging 2 x features which worked perfectly separately before. I take it this merge of features will somehow help the new navigation being pushed out. Currently to add a new restricted user, you have to 'share', not save. I have multiple users contacting me saying they can no longer share, when really, they are seeing the 'You do not have permission to change access to this content', meaning they can't change the restrictions, which has nothing to do with sharing. This is clunky, confusing and embarrassing. There are so many bugs which require attention, meanwhile, time is spent making the GUI less user-friendly. I'm really disappointed with this change. Sharing and Restrictions should be separate. However, I do agree when you try to share with someone who doesn't have access, you should receive an alert. Restricting access is a security feature which is restricted to particular users. Users who are trying to share a page should not be confronted with messages saying they can't restrict. Counter intuitive. 

[Marie Casabonne]

Hi @Darryl Lee

Thanks for your feedback. With this release, the Share button copy link action and the copy link action in the modal footer both build links in the following format: <mysite>.atlassian.net/wiki/x/XXXX 

Any links that follow the other format (<mysite>.atlassian.net/l/cp/XXXX) will still work and redirect to your content.

Sorry to hear about the scripting challenges with the short URLs. I’ll circle back to this comment after I touch base with a few teams to see if there are any other solutions we can recommend for getting the pageID from the short URLs.

[Marie Casabonne]

Hi @Steve Rhodes 

Yes, you’re spot on! This release is a unification of the two experiences you mentioned (access management via the restrictions dialog and sharing via the share dialog) into a single workflow. In addition to the features you highlighted, we also introduced blocked access awareness when sharing with individuals who will not have the necessary access due to parent content restrictions or space access. This integration lays the groundwork for future enhancements we plan to introduce noted in the "What's coming next" section above!

[Marie Casabonne]

Thanks for your questions, @Amy Carey 

Yes, the default for sharing is notifications on. As of now, there is no global toggle to turn this setting off.

[Marie Casabonne]

Hey @Don McFall

I understand how important sharing with Teams is for your workflow, and I'm sorry for the inconvenience caused by its temporary absence. We made the tough decision to release the new sharing experience without this feature because Teams currently can't be granted access to content or spaces. Rest assured, bringing back this functionality with full support to share and grant access to Teams is a priority for us, and we're working on it.

[Marie Casabonne]

Hi @Shelley Duncan , 

Thank you for sharing your feedback. I understand the transition to a unified access and sharing workflow has been challenging, and I'm sorry for any frustration the changes have caused for your users. While this change is separate from the new navigation updates, it is part of our broader effort to modernize Confluence's user interfaces and workflows.

Regarding your concerns:

• Adding a user to restricted content: You can still grant access without notifying the user by unchecking the “Notify newly added people” checkbox. This allows you to add users without sending them a notification.
• Sharing content that you cannot manage access to: The unified workflow now manages both sharing and access. If users can only share content due to restrictions, we inform them in the modal to prevent confusion about access permissions.

I appreciate your feedback and am glad you find the blocked access awareness feature useful. Your input is valuable as we continue to improve the sharing experience.

[Shelley Duncan]

@Marie Casabonne  but it is causing confusion. A user who cannot restrict, but can share is presented with this 'You do not have permission to change access to this content', and they automatically think they cannot share. All of a sudden, 2 simple and obvious features have been merged, causing mass confusion.  This is not user friendly at all. I can't even access Restrictions via the ... menu anymore. If it isn't broke, don't fix it. This was working perfectly before, now, not at all. If users have to ask how to use a basic feature, you haven't done your job properly. 

[P_D_ Foerster]

I'm torn by the change as other have already commented.

Please also think about the following:

• Example user John is space admin and is able to grant other users and groups access to space content via the new option "add to space" during the modal "some people need additional access".
• John shared with a group instead of single users and added it to the space as suggested (blue button background).

Does John know who is member of that group? 

As far as I know only user access admin, site admins and org-admins are able to view group members.

It could be that the group contains external users and John isn't aware of it.

❓ Questions

• Do you have plans to show group members to users who are trying to share content with that specific group?
• Do you have plans to restrict available groups only to those that the current user is a member of?

[P_D_ Foerster]

-- removed --

Reason: community platform is too slow in general and displayed agreement again.

[s_weber]

Hi @Marie , 

we had a look at the new feature-set and we are quite worried, it would harm our secured environment which follows a very sturdy, stable, standardized and de-centralized way of granting and revoking access.

Generally a good idea to simplify this,  but for larger ecosystems, it falls a bit short and poses a huge risk in access management. Users / Space Admins are unaware of the consequence of their action and therefore can not even assess, if it is a good idea to provide access in the way the system is proposing them to.

How are we currently setup?

For over 10 years, we have had 3 default Roles for each JIRA-Project (over 170 in total) and each WIKI-Space (almost 300 spaces)

1. Admin (Full Project / Space Admin rights)
2. User/Developer (working in the Project or Space)
3. Guest (Reading and commenting)

Each Role is directly connected to an Active-Directory Group, which gives us freedom to manage (add, remove, adopt) the access based on many factors, standards and internal processes.

It also directly feeds our Audit log and revision for full transparency. For JIRA and Confluence we have almost 2.000 Groups to manage all of this and its working like a champ. We also use the Groups to provide access in multiple places inside the Atlassian Ecosystem, but also in connected Ecosystems, like SharePoint.

What is a scenario, where this is useful?

• A user in our company can go into a Self-Service, request permissions to a Space or Project and the Owners receive it, approve/change/deny the request. In the end, the user is placed into a dedicated Active directory group and get all the right permissions automatically.
• A new User joining an R&D Software Team needs on average about 200 permissions. He has to request 0, as we have a full description of his role and all the access required in JIRA, WIKI, GIT, Jenkins etc... Nothing needs to be done
• A user is leaving R&D to join our sales Department. We need to remove all the cool access to R&D Projects. Currenlty we have to do nothing, our intercompany-change-process will cleanup his permission in the AD for us.
• These are just a few, we have many of these and much more to come.

What are we in fear of?

We are in fear of users being manually granted access as an individual user. In JIRA in the "People" Panel and in Confluence in the Users Panel. Once this is the case, our approach is broken, we have gaps, security risks and no one-stop-shop to see all of a users permission in all systems.

1. If a user changes from R&D to Sales, we can no longer revoke all additional-permission from secret projects. Its fully out of our hand and it would break our "Intercompany-change-process" completely.
2. We experience a tough time, debugging why a user has access, but maybe not full access, as he is added as a user to a space, but not to a group, which provides extended access inside Atlassian
3. We experience users being able to access a Confluence page, but not the connected SharePoint folders within, as only Confluence knows that this user has the correct permissions. SharePoint is unaware of this
4. We no longer have a clear log which the internal revision or other auditors may view, to see who had access when, where and granted by whom. We would need to check the Audit log in Atlassian, which is only kept for 180 days.

Please give companies a choice / a permission to define if users can add people this way or not. Just like Exporting a space is a permission, managing users should be as well.

We know it has been there, we have always trained our users to never use this. In reality it does happen, but in this case, the user was fully aware of his actions. With the new UI Experience, the user does not even know what is happening behind the curtain and its tough to teach this knowledge.

I am up for a direct contact, in case you need to discover more.

Thank you and BR

Sascha

[Marie Casabonne]

Hi @s_weber , thanks for your detailed use case overview. I want to clarify that the new sharing experience and the blocked access awareness flows are specific to Confluence only - none of these updates impact Jira.

I hear your concern that with the AD and group-based Confluence access management system you have set-up, enabling space admins to add individual users to spaces through the blocked access awareness modals breaks with your process.

We're happy to take the suggestion to allow admins to turn off this functionality.

@P_D_ Foerster - thank you for your feedback as well. You're right that users may not have visibility into who is in a group that they are sharing with if they're also not product admins. Answers to your questions below

• Do you have plans to show group members to users who are trying to share content with that specific group? - We have plans to show the count of users. We don't have plans to show the exact users in the group, but I'll take it as a suggestion and explore it with my team 
• Do you have plans to restrict available groups only to those that the current user is a member of? - We don't have plans to restrict sharing to only groups that the sharer is a member of. Groups are used for sharing/access management at scale, and barring users from sharing with groups that they are not a member of would greatly limit many customer's workflows.

[s_weber]

Hi @Marie Casabonne , 

awesome, thank you for the elaboration around JIRA and for adding the switch for Admins :)

BR

Sascha

[s_weber]

Hi @Marie Casabonne , 

the feature is there now. Where can i find the feature / Button to disable the part where users can also grant permissions?

Thank you :)
Sascha

[Marie Casabonne]

Hey @s_weber there is no way to disable the ability for empowered users to grant access (when the person they are sharing with will be blocked by parent content or space access) yet. I had already noted it internally, but I think a public feature request is the right approach.

To help me craft a clear feature request on our public system, can you please clarify exactly what you would like to have control to disable?

• Do you wish to disable blocked access awareness AND one-click fixes for empowered users, or just the one-click fix part of the feature?
• Do you wish to disable this for both parent content and space level access problems, or just in situations where a user's space-level access will be updated?
• Are there any other specifications?

I'll create & share a public feature request once these details are confirmed. thanks!

[s_weber]

Hi @Marie Casabonne , 

I was unaware that you need more, by your reply I personally figured it will already implemented with the go-live.

• For us it would be enough to see a global System / App-wide control, regarding the one-click fixes active or not. (We would disable it)
• Ideally we would also love to see an additional permission besides the "Admin permission" of a space, on who is allowed to change / add / remove permissions (for groups and users)

hope this helps. 

Let us know the Public request ID, so we can vote and monitor.

Thanks & BR

Sascha