Request Space access coming to Confluence!

[#1]

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

Soon, end users will be able to request access to a Space. Currently, we only support requests for access to Confluence content. In the coming weeks, we will begin rollout. 

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 users that have permissions to grant Space access.

 

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 ! =)