Feedback by UserVoice

I suggest you ....

Optimize Access Request Settings for site owners

Three requested updates to significantly improve the Access Request process:

1) Allow multiple users to receive access requests

Access requests (Site Settings > Site Permission > Access Request Settings) can be sent to anyone with an email address, but it has three critical downsides: 1) you are limited to one email recipient; 2) the field does not accept SharePoint groups; and 3) it’s prone to misspellings of email addresses since the field is not a people picker.

One of the most extreme examples of how this is broken: My company’s CEO needs access to a file s/he has a link to, which s/he is going to display at the board of directors meeting in 15 minutes. The site owner forgot to give access or didn’t realize the CEO lacks access. The CEO requests access after clicking the link. The creator of the site has left the company. The request email gets lost in Exchange somewhere. No one knows the CEO is in need of access and the CEO is unable to present the document to the board of directors. Everyone looks a fool.
The best fix for this is to: a) use the site’s Owners group as the default recipients to start; b) allow for multiple email recipients as a people picker; and c) continue accepting an outside email address for those who have grown used to it.

From what I can tell, this is the only place in SharePoint where I'm limited to one individual and no ability to call out SP groups. The entire point of groups is to ensure permissions and communications work correctly based on a global change at the group level, which keeps things moving smoothly.

2) Display site owners on “Request Access” page

Display the names of the members of the Access Request group on the “Request Access” page so users have context to what they’re seeing, not just a blank box asking them to demand access.

3) Make “Request Access” page customizable

Allow for the “Request Access” page to be configurable by the Access Request group so there’s more context for users. For example, “Please do not contact IT with this request; only the site owners can provide access. Contact them directly if necessary.”

265 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Matt Wade shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Comments are closed
  • Akmcm76 commented  ·   ·  Flag as inappropriate

    The response does not cover the full scope of the request! Why is this closed? You only provided a small part of the request, to provide a custom message on the access request page.
    What about the first part of the request:
    1) Allow multiple users to receive access requests

    Access requests (Site Settings > Site Permission > Access Request Settings) can be sent to anyone with an email address, but it has three critical downsides: 1) you are limited to one email recipient; 2) the field does not accept SharePoint groups; and 3) it’s prone to misspellings of email addresses since the field is not a people picker.

  • Alison commented  ·   ·  Flag as inappropriate

    This change was poorly executed. Please realize the impact a change to SharePoint can have on other products that use and are integrated with it.

    As others have mentioned, it does not give you the ability to choose a group - it assigns one (the 'Owners'), but that doesn't apply in all cases, including ours when using Project Online that uses SharePoint Online - the assigned group are the Web Administrators for the PWA and you cannot change it to the actual owners of the SharePoint sites that are associated with the projects. Instead the Administrators have to field every single request for projects that they do not work on - merely set up and administer. I can type in an email but it really doesn't matter since that person have to be a member of the group to accept/reject the requests. Plus I cannot type an email that is not associated with an AD account - well, I can but it doesn't send it to the email. This was an attempt to forward the requests to a group email more appropriate than the Web Admins. Like others we don't want it to go to a single person since that can lead to other problems when they leave or are unavailable. I know you are moving to a 'hub' system with the new direction of SharePoint versus use of subsites - but I would assume every single instance of Project Portfolio Management system using Project Online and SharePoint Online is using subsite and the 'site owners' of the system should not be the only group to be managing access for all the project subsites that are created. We have over 100 projects/subsites and I imagine there are companies with more than that.

    Please make some changes to this to allow companies to better manage this. We cannot have an open system but we need to have a better way to allow us to manage access. For all intents, you have essentially decided it for us. Please let us decide! This has become a huge burden on our web admins...

  • Renee Barnette commented  ·   ·  Flag as inappropriate

    The article:

    states that what is displayed in "Access Requests Settings" is in SharePoint Server 2013, but it is not there (at least not as of the April 2018 CU, and I see no indication from the KB it's updated for the May 2018 CU for SharePoint Server 2013).

    What CU for SharePoint Server 2013 will that be released with?

    If it is not currently in the works for SharePoint Server 2013, please consider adding it for that version and let us know/reopen this for 2013 (and other versions where it may not already be added), and if not, modify the information in the support article since it's not available in SharePoint Server 2013.

  • Greg Ogle commented  ·   ·  Flag as inappropriate

    I just installed the May CU for Server 2016 and I do not see this update. Is it planned for the June CU?


  • Anonymous commented  ·   ·  Flag as inappropriate

    Unfortunately there's still no possibility to add a group instead of hardcoded e-mail addresses... :-(
    It's a pitty only plain text can be added, would be great to have some markups or some placeholders (e.g. <MemberOfOwnerGroup> which displays the names who can be contacted.

  • Effy commented  ·   ·  Flag as inappropriate

    What about SharePoint 2016?
    Is there a CU to install to enable this new feature?

  • Sasha commented  ·   ·  Flag as inappropriate

    We DON'T want all Web Administrators to receive access requests! We want just project owners to receive them. Do we have to change the setting for our nearly 700 projects one by one?!? Thanks.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Really a shame that we cannot choose the group that will get the requests. Makes the feature pretty useless...
    Good job on the message though

  • Matt Wade commented  ·   ·  Flag as inappropriate

    Not fully to the level of the original feature request, but a huge improvement nonetheless.

  • Troy Phillips commented  ·   ·  Flag as inappropriate

    The article linked above is only scoped for sites. Will this be a broadly released feature?

  • Rachel Davis commented  ·   ·  Flag as inappropriate

    The point was to be able to CHOOSE a group to get access request settings.

    We don't use the "Owner" group. Without that, it seems to be choosing kinda randomly. For one site, it chose a group with Contribute access.

    An then there's the warning that "only members of X" group can accept/decline access. BUT IT CHOSE A GROUP THAT DOESN'T HAVE ACCESS APPROVER PERMISSIONS!


    Good job on the custom message though.

  • Benoît Fournier commented  ·   ·  Flag as inappropriate

    Looks like it's coming... but not much details. Lots of expectation.

    New feature: Customization of the Access Request Flow in OneDrive and SharePoint Online
    Stay Informed
    Date de publication : : 24 avril 2018
    Customization of Access Requests is a new Office 365 feature. We'll be rolling this feature out over the next few weeks.

    This message is associated with Office 365 Roadmap ID: 27559.

  • Benoît Fournier commented  ·   ·  Flag as inappropriate

    An update please. Can we expect a solution soon? Is it in the roadmap?

    We will need to start coding a workaround soon. We need a way to handle access requests with a Flow or a WebHook. At least a configurable URL to put our own logic.

  • Amy commented  ·   ·  Flag as inappropriate

    Please, can we get an update? We need this!!! It is crazy that you can only add ONE email address. It is crazy that end users can't see who owns something....they have no idea where their access request goes. It's been a decade of this!!!

  • Tom Braman commented  ·   ·  Flag as inappropriate

    [Continued from last comment]

    5) Give Site Owners more options to correspond with requesters upon receipt of a sharing request. Give them the ability to include a message anytime they "Decline" a request (currently this is possible, but requires two steps and two messages--bring these together). Give them the ability to "Ignore" (or 'delete') sharing requests (or at least move them from pending to history), and including the simultaneous message-user feature described above. Finally, make sure that when a Site Owner accepts a sharing request, a (customizable) message goes back to the requester documenting the specific permission they've been granted (permission level, and resource).

    6) Improve the email/website experience. Currently, sharing requests arrive at a Site Owners email box with both "Accept" and "Decline" options, yet regardless of which one is clicked, the Site Owner has to perform the same click on the Web site, and worse using different language. "Accept" becomes "Approve" or "Cancel." What does Cancel do? Nothing (i.e., close the Web site dialog box), or does it cancel the request?

    7) Insure the User Interface is accurate. Upon clicking "Accept" in a sharing-request email, the Site Owner is confronted with the option to Approve, with a sometimes incorrect explanation of what will happen. For example, I've seen that the user "will receive edit access" when actually, if granted access to the site's default group, the user will receive Contribute access. Like in No. 2 above, here the Access Request Process makes faulty assumptions about user needs and inadvertently steers the Site Owner in a confusing if not wrong direction.

    8) Insure that all group owners are notified whenever a new user is added to a group, or at least give authorizers that option. This will help prevent others who may be notified to add users from attempting to do so redundantly.

    9) Usability-test the heck out of this before releasing it. Share it with those who have responded here, as we all have invested energy toward a better version.

    This is just a quick brain dump. This whole process could use a full overhaul that starts with a renewed inventory of requirements. Happy to help document what I believe those would be if anyone could use them.

  • Tom Braman commented  ·   ·  Flag as inappropriate

    Additional ideas:

    1) Break up "Manage Permissions" into two permissions, one to create permission level on the Web site, and another that gives users (such as Site Owners with less than Full Control permissions) the right to change permission levels up to their own permission level on the Web site, to assign permissions to users and groups, and to view and access "Access Request Settings" on the Site Settings page. Currently we don't grant "Manage Permissions" to our Site Owners because we want to centrally manage permission levels. However,
    we would really like them to be able to change permission levels up to an including their own permission level (a custom permission we call "Manage," because we don't give them the full-control permission level).

    2) Eliminate the current practice of accepting sharing requests that automatically places a user in the site's default SharePoint group. We don't see any value/purpose of the site default SharePoint group -- and in this case, it makes it far too easy for a Site Owner to add a user to the wrong group. It's not clear from the Access Request what type of permission the requester seeks (view? contribute/edit? other?), so the Site Owner is flying blindly unless he/she contacts the requester (which is what our governance currently requires to overcome this). A better solution would be to a) insure the requester conveys the type of permission he/she needs (read/write), and the level of permission as well (file/list/site), and b) give the Site Owner a clear path to grant that specific permission, ideally by placing the user in a group rather than granting direct permissions.

    3) If there's justification for keeping the default SharePoint group (again, I don't see one), then the verbiage in the dialog box that appears after clicking "Access Request Settings" on the Site Permissions page (_layouts/15/user.aspx) needs to change, from "Allow members to invite others to the site members group,*" to "Allow members to invite others to the site default group,*". It's confusing currently when the a site's default group is a Visitors group, and this phrase results: "Allow members to invite others to the site members group, X Site Visitors").

    4) Related to the above, document the heck out of the entire Access Request / Sharing process. It took me many, many hours to understand the vagaries between "Allow members to share the site and individual files and folders" (how can they do that if I've given only Site Owners the right to add users to site groups?) and "Allow members to invite others to the site members group, X. This setting must be enabled to let members share the site" (If this isn't checked, then how can the preceding one be checked? Because the preceding one allwed "members to share the site," but this one prevents it? Does the latter cancel out the former? What what? Another example: If Access Requests are sent to the email in the Access Request Settings, what happens if that person is not a group owner of the group the user needs to be in? Also, within a specific group's "Change Group Settings" page, there's an option to "Send membership requests to the following e-mail address..." -- does this address just a user's own request, or does it also handle sharing requests to this specific group (i.e., does it trump the email address in the Access Request Settings dialog box? All this took tons of time to decipher, mostly by trial and error, trial and error. Comprehensive and clear documentation would save us all collectively so much time!!!

    [More in next comment]

  • Thomas Bak commented  ·   ·  Flag as inappropriate

    Could you please provide an update on this? Last update was a year ago and then it was "in the plans". Would be great to understand if you started working on any of it or what's keeping you.

  • Benoît Fournier commented  ·   ·  Flag as inappropriate

    Any update? We need to handle access requests automatically. Our only way to do this now is with the e-mail sent. Definitely not the best solution.

    Give us webhook or Flow actions,

← Previous 1

Feedback and Knowledge Base