Request Space access now in Confluence!

[#1]

Hi 👋 team, another exciting update from the Confluence Permissions squad!

Now, end users will be able to request access to a Space. Currently, we only support requests for access to Confluence content. 

In the new experience, end users will be able to click, “Request Space Access” when they do not have access due to Space permissions.

Once the user requests access, it will send an email notification to select administrators. Specifically, it will send an access request email notification to Space administrators that are directly added to the Space (i.e. those visible on the “users” tab). We will select 20% of those admins, rounded up to a maximum of 5 admins. 

 

When the user clicks through, they will be able to review, edit, and grant the access request in Space permissions.

Please let us know if you have any questions or feedback!

All the best,

Kristen and the Confluence Permissions team

[Andy Gladstone]

@Kristen Waters this makes so much sense, I am not sure why I never realized it was not an option before.

Your article mentions that the request will go to the Space Creator. Do you mean the sole Space Creator, or any Space Admin in the space that access is being requested for?

[Chris Buzon]

This is a huge improvement!!

[Rita Nygren]

Internal enterprise wiki here....   The people who *create* the space is the IT department, who do it on behalf of someone who tells us how they want the space permissions set.  If a general user clicks a link and gets to a restriction to a space, its likely because we don't want them wondering around this restricted space.  What you are doing is making more work for IT.

Can I turn this off?  (Granted, it makes sense in other environments.  I would love for this to be option, even at the space level.  But I don't want people asking for access to say Legal or HR private spaces as the answer is No.)

Also:  many of these spaces were created a long time a go in a galaxy far far away (May the 4th was this last weekend, sorry) - the person who created the space is long gone.  Who's it going to bug with these requests?  The instance admin?  I have enough to do, thanks.

[Filip Labarque]

This is a step back for us.

Spaces are created by IT, but IT does not manage the permissions of the space.

IT will need to redirect all these requests back to the space admins. Please let this feature be configurable.

[Steve Rhodes]

In our place, IT always create the space so this will just create more spam for them. People already create a ticket when they want access, and this is the way we would like it. Also, people in the IT department will eventually leave the company and the person who created it will then also not even receive the request (and probably spam an account that is already deactivated, and end up on the internal Atlassian email blacklist).

If you were to roll this out along with a designated Space Owner field (a bit like Jira's Default Project Lead and Default Assignee fields in the Details section) then this could be kept up-to-date and would be far more useful.

Its a great idea, but a bit half baked at the moment.

As it stands, the first thing I would want to do it switch this off.

[Jenny Severin]

I would prefer that the user raise a request for access through our JSM portal. Unless this request can automatically direct them to our JSM portal or create a ticket in JSM, I would also want to turn off this feature as we have a request type that gathers more details on why the user needs access so the person approving the issue has more information.  

[Kristen Waters]

Hi all - good feedback on this feature. 

Good news here is that our roadmap is aligned with your feedback. Right now, there is no user initiated signal that they need Space access. It is nice to bring this flow into product so you don't have to configure yet another process to manage this/users have to find that process in order to get access. What I'm hearing you want next to make this more valuable:

1. Ability to designate someone to manage this access closer to the work (like a Space owner)
2. You'd like more information on why the user needs the access (sometimes gathered in a JSM request)

I have two follow-up questions:

If there were an request access hub in the Space, would you want JUST ONE person to respond to the requests? Or would it be a group of 'managers' in the Space that have user management permissions? 

For more immediate follow-up logic on who gets this requests, would you prefer a group of space admins (perhaps the most recently active space admins) to get these requests? 

Thank you for your engagement and your candid feedback. This community helps shape our features, and I appreciate it!

-Kristen

PS @Andy Gladstone correct, the space creator alone gets this access request. If you do not want to respond to this in-product, you can point them to a current process, or direct to space admins (Space Settings>Space Details> admins are listed at the bottom)

[Steve Rhodes]

Hi @Kristen Waters I would say at least the space owner should get the request. If we make it a hard coded -all people with space admin rights- then there are some spaces that have dozens of admins and we would be spamming them. Plus, ICT always get admin rights so ICT would get spammed anyway. Ideally if it can be a named group, but if not, the future space owner. Perhaps a multi user field.

This feature should serve as a way to lighten the load of ICT, not make it worse. So, if this access request can be sent to designated people/person/group then that would help a lot. I'm just not sure what security would think, but as it is, people can randomly contact a space admin and ask for rights. I think if site-admins/user-admins/org-admins can opt in to receive these requests it would help.

[Filip Labarque]

@Kristen Waters a single user would not be sufficient, it should be a group of space admins.

[Rita Nygren]

I would live with a designated owner (who would then make a a JSM ticket if they approve it) or a means to just route the request into a JSM queue, but I'd really rather they didn't have the button at all.

[Kristen Waters]

Hi team - given this valuable feedback, we are making a quick change to the notification logic, and for a longer-term fix will continue to explore the 'space owner' functionality in partnership with our Admin Experience team. 

In the short-term we are wanting to move away from sending notifications to the space creator, but instead a select group of admins. We're working hard to find the best signals that an admin is engaged with the space. 

Stay tuned. We are wanting to bake this in before further rollout. Changes will come in the coming weeks. 

[Tere Pile]

Slightly lost in the comments - McDonalds this my understanding (i.e. repeating in my words) :) 

* Creator (originally planned)

* Space Admins (some want this)

* Confluence Admins (given this is a new role, maybe an option)

My personal preference would be space admin, I presume most have a group that is by default given space admin permissions. In our case this group is also the ones who have ability to Create spaces.  More persons in this group than Confluence Admin or Org Admin and given age of many instances, the 'creator' likely isn't very clean (i.e. deactivated user). Granted owner can be changed now, (pages/not spaces, ugh).  Regardless how many have taken that on? 

I really would prefer NOT having another 'option' :) 

Follow up question which is - if one doesn't have permissions to Confluence at all - what is the anticipated behavior?

[Filip Labarque]

@Kristen Waters Great news! Thank you for being so open and reactive to feedback.

[Danja Karenko]

Based on our experience, it would be good to be able to choose per space who gets notified of an access request:

• a group
• several groups
• an individual user
• multiple users

...in the same manner one can grant page edit/view rights to groups and individuals.

Like many others in the comments, we also have a smaller group of super users who create new spaces for other other teams. After handing the space over to the users, those super users have no way of knowing who should or should not access the space contents.

Having the option to disable this feature (globally and per space) and point people to a Jira form instead would also be great.

Thanks for listening to the feedback, @Kristen Waters ! =)

[Kristen Waters]

Hi all - thanks for your engagement on this feature. TLDR; We have made some changes to the request logic and will begin rollout today. We are also actively exploring a Space Owner designation for launch.  

Logic changes to request email notifications:
In order to move away from all requests going to the Space Creator, we will send an access request email notification to Space administrators that are directly added to the Space (i.e. those visible on the “users” tab). We will select 20% of those admins, rounded up to a maximum of 5 admins. 

In partnership with the Admin Experience team, we are exploring a designated Space Owner that can be the single point of contact for the Space. This will help streamline and manage access requests and other administrative tasks for the Space. These can be trusted individuals that will manage access requests in product. 

[Rita Nygren]

Since I keep all of my permissions in Azure groups, including space administrators, and it's rare that there is a human in the Users tab, this would mean no one gets this notification (unless I add someone there, or until we get the Owner field)?

[Kristen Waters]

@Rita Nygren By default when a space is created, the space creator appears in the users table. They can be removed if there are admin permissions in the Groups table.
In this case, we will throw an error when user clicks on the button to request the access. Per feedback, we will not send the email to space creator as the special case.

Again, for these longer-term fixes, we'd like the concept of a Space Owner, who would be notified as the single point of contact for the Space (for administrative and access request tasks).

[Belinda M]

How can this feature be turned off please as we have policy that these types of requests need to go through our ticket system so that we have a proper audit trail in place?  

[Mariam Slade]

@Kristen Waters 

I have a couple of questions, 

1. How are the 5 admins selected? Is it based on some type of metric or is it at random? 

2. A few people have asked this, but I can't see any response. How can we turn it off? This will disrupt some of our existing processes and is likely to cause problems. 

[Vesa Purho]

We also have issues with this as there currently is no way of turning this off. We are handling the space permissions through user groups and not by giving individual persons directly access to a space. With this the space admins get requests that they should not process. This would be great if the space admins could decide to add the person to a group in the Groups-view but I assume that would then require all the space admins to have User Admin -role, which they don't. 

There is a feature request to make this feature configurable so that it could be centrally turned off, please vote for that: [CONFCLOUD-78577] Option to Deactivate Space Access Request Feature for Admins - Create and track feature requests for Atlassian products.

[Mariam Slade]

For anyone who is interested:

Support have just confirmed that the 20%/5 admins are chosen at random. 

This is going to cause a lot of problems for us and I'm sure a lot of other organisations would feel the same. We would really prefer to turn it off. 

I would really appreciate if everyone can please vote for this feature request, to add an option to turn off space requests. 

[CONFCLOUD-78577] Option to Deactivate Space Access Request Feature for Admins - Create and track feature requests for Atlassian products.

[Ignacio Pulgar]

This feature is great and it was needed from long time ago! :)

Regarding the notification logic, why a maximum of 5 users?

I'd suggest the following logic when a user requested access this way:

1. Send an email to the Space Admin directly added to the Users permissions who most recently used Confluence.
2. Wait for 5 minutes.
3. Has the request been either approved or rejected?
   1. If so, nothing else needs to be done and the process ends.
   2. Otherwise, send a notification email to the next most recent Space Admin who had not been notified so far.

This process would be repeated in a loop until either the request were processed or the last Space Admin had been notified.

If all individually added Space Admins were notified and still the access request were not either approved or rejected, then the notification process would start looking for addicional Space Admins who get the permission from a group membership.

I think this logic would:

• a) Minimize the number of email notifications sent.
• b) Minimize the situations when a Space Admin receives a notification to provide access which had already been processed by another Space Admin.
• c) Maximize the likelihood that the request is processed.
• d) In the long run, it will also produce the best processing times, since users would know that situation b) won't happen that frequently.
  
  With this logic in place, space admins would think: "If I am receiving this email right now, it is because no one else has approved or rejected the request so far, so my action will be decisive for the end user to get the access they need in a timely manner."
  
  With the approach of sending the notification to 5 space admins at the same time they would think: "Oh, another of those notifications for providing access that I can approve just 20% of the times (I'm the fastest approving admin just 1 out of every 5 times). I'm quite busy/lazy, so anyone else will process it."

Btw, are we also having a similar functionality for requesting access to Jira projects? That would be awesome!

[Filip Labarque]

This feature request should allow us to configure who gets the space access requests: CONFCLOUD-79172 

[Rachel Davis]

@Kristen Waters I like the idea of a designated Space Owner who would get all the comms for the space.  That seems like it would solve alot of the issues mentioned in the thread. 

Please make sure that we can designate 2 or 3 people (not unlimited) and that ALL Space Owners get notifications. That way if someone is on vacation or unexpectedly leaves the company, we have at least 1 back up remaining. Thx.

[John Hooper]

Thank you everyone for all of the feedback! I wanted to share that Confluence will be beginning to actively investigate the addition of the space owner capability soon, and that we currently plan to begin engineering work on it in the next 2-3 months

If anyone has any additional context they'd like to share, please feel free to leave more info here in the comments of this page or to book a call with me here. 

Thanks!

John