Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How does "Request access" work in Confluence?

When user accessed a restricted page, user can send a request to the last editor to get access to the page.

Can the request be sent to space owner since that user is the owner of the space and decides who can access and who can't

5 answers

4 votes

Hi everyone, 

A quick note to let you know that in Confluence 6.8 we've improved how request access works under the hood.  When a user requests access to a restricted page, Confluence will send an email to up to 5 people. It chooses people in the following order:

  1. people who have contributed to the page in the past, can see the page and have 'Restrict' or 'Admin' space permission (sorted by last edit date)
  2. space administrators who can see the page (sorted alphabetically).

This means that the request should be actioned quickly, as it prioritizes the people who have been interacting with the page most recently. 

So this has created an unfortunate scenario where some of our jira/confluence admins - people who really have nothing to do with the space are getting all of the request for access emails.

We have to have one group that has admin on every space, but we have no way to designate another group as the ones who should be receiving these emails as they both have space admin.

Right now one of our jira/confluence admin's name starts with Aa so he gets every single email from all spaces.

Anyway to delegate a specific group to always receive these emails?

Like Stefan_Niklas_Hoffmann likes this

Hi Chad,  

Thanks for letting us know, I can see how this would be problematic.  I'll raise it with the dev team. 


We had hoped that in most cases, the request would be sent to someone who has been interacting with the page itself, but sounds like in your case that few people have the 'Restrict' space permission? 

Like Stephen Garber likes this

Ooooh wait a second.

So I can remove the restrict permission from the space admins and they won't receive these emails anymore - that fixes my routing issue.

I just submitted a ticket for a similar issue with us not receiving emails at all.  But I'll wait for their response.

Thank you for the quick response!

Sorry, that workaround won't work - as Space Admins are always able to restrict and remove restrictions / grant access (regardless of whether they've explicitly been given the Restrict permission). 

The only workaround I can think of is to actually grant more people Restrict permission, so that the pool of non-admins that can grant access is larger - but that may not work for your organisation (as these people would be able to restrict content as well as grant access). 

Same problem exists at our site. Most of the time there are not that many editors or contributors to a page. So the space admins (and in our case the system admins as they are always space admins) will receive a mail. I've got no great idea how to solve that problem: I like the request being delegated to more persons than just the editor/ last author, including the space admins seems to be the right thing for most use cases.

Maybe a configuration switch or a default delegation email address could ease the problem...

Here is what I did that I think is working from spot checking all my spaces.

Create one global "space admin" or just use "site-admin" either or.

Create a space specific admin group. IE: admin-product

Add the users who should receive requests and manage the space to admin-product.

Give all permissions to space admin group ( or site admin ) but remove the restrict permission.

Doing this changed the routing of emails to go to the admin-product group and not our site admins or space admins.

Hope this helps.

Is there any further, more detailed information on to whom access requests are sent?

states that it chooses people in the following order:

  1. people who have contributed to the page in the past, can see the page and have 'Restrict' or 'Admin' space permission (sorted by last edit date)
  2. space administrators who can see the page (sorted alphabetically).

So this means

  • Requests are always sent to 5 people, except if there are less in 1. and 2. together
  • If there are more than 4 contributors with 'restrict' rights (not including space admins), no request mail is sent to any space admin at all (except if a space admin is among the most recent 5 contributors)

As a space admin or confluence admin is there any chance to find out to whom an (unresolved) request was sent to?

I came across an issue regarding this thing, not sure if i can ask here or i have to open a new discussion. 
We have a page in confluence that is restricted. I am a site admin, i`ve added myself from page permissions with full rights as well but i`m still unable to view the page, is giving me the "request access" view.  The same issue for my site admin colleagues and for the person that requested view rights on that page initially.
Note that the page was created 2,5 years ago by a colleague that is no longer working with us. Also the request goes to a user that does not have site admin rights but has full page rights (as i have)

As far as I found out, there is only the chance to disable the Plugin completely.

Therefore you need to go to "manage addons" > "Show all addons" > "Confluence Request Access Plugin" then hit the disable button.

Anyway I would prefer a solution where I can define who will get the request for access.

It would be nice if it could be tied to the administrator permission set in space permissions. But here is the Confluence documentation regarding this plugin:

OMG, with 10000 users and 1000 spaces we do get many of these spam mails to the admins. I ask myself sometimes who is defining requirements at Atlassian and what they smoked at this time :-)

Such mails should never ever go to SystemAdministrators. They could not even know if a right could be granted or not. This has just to be distributed to local space admins or the most recent people editing a page.

Per the documentation at the space administrator can grant users and groups to have permission to restrict (edit and view) pages.  Note that permission to Add pages (and edit content) is not the same as the permission to restrict pages.

Hope this clarification helps!

We have this same issue, where the individual who grants access is out on vacation. I am a site admin. I go to Space Settings and add the requesting user to the page. They log out and back in. Still no access. Anything I'm doing wrong here? This is pressing, as Jira has no live support and we have users who can't get work done.

Hi @jbarr, sounds like the page itself (or a parent page) is restricted.  You'll need to go to the page and add the person in the page restrictions dialog. 

See for how to do this   (or if you're using Confluence Cloud). 

The permissions tab in Space Settings controls access to the whole space, but sounds like in your situation that the page itself might be restricted. 

Hope this helps. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Confluence

Announcing Team Calendars in Confluence Data Center

Hi Community! We're thrilled to share that Team Calendars for Confluence is now a built-in feature for Confluence Data Center releases 7.11 and beyond.  A long time favorite,  Team Cale...

103 views 0 3
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you