If you own a SharePoint site, I am sure you followed all the best practices regarding the site security setup and permissions. However, you might also want to control the experience of the users who do not have access to the site just yet, but who might need one. Likewise, you might want to view pending access requests at any point in time and either approve or reject them. In addition, if you happened to share the site externally, you might want to track who accepted your invite and who did not. I know I listed a few different scenarios in this article, but they will all be answered by the wonderful feature of Site access requests. Buckle up and enjoy another sermon of wisdom from rabbi Zelfond. By the way, you might want to read this post till the end as I also cover some important and unintended consequences of SharePoint access Site Requests.

Default User Experience

By default, on any given site, when the users who don’t have access to that site, when clicking on its URL, will get this message.

Here they can add a personal message and press the Request Access button, and request access to the site.

You can customize this page and either disable this button or control who the requests go to. Let me explain.

How to disable Site Access Requests

If you do not want users to bother you with these requests, you can disable them altogether.

1. Navigate to the SharePoint Site, click Gear Icon > Site Permissions
2. Under Site Sharing, click Change how members can share
3. Toggle the switch next to Allow access requests to Off and click Save
4. Once disabled, the user will get a nasty message when navigating to the SharePoint site URL: Access Denied. The user does not have permissions to access this resource.

How to specify who the Site Access Requests will be emailed to

Alternatively, you can also specify who the Site access requests will be emailed to. By default, they are sent to the Site Owners. However, you can also designate an alternate email address. It can be an email address of any user, and can even be an external email address as well. And you can also add a custom message to the request access page if necessary.

What happens to the user when you approve or reject requests

When the user requests access to the site, here is what happens:

1. The Site Owners (or whoever you designated to receive these emails) will receive an email like this
2. The Owner can either Accept or Decline the request
3. In case the request is Declined, the owner will need to confirm the intention
4. When navigating the site again, the page will display a message: Sorry, your request has been declined.
5. The user will also receive an email advising that the request has been declined
6. In case the request is Accepted, the user will immediately be granted access to the site and receive a corresponding email

How to access pending and completed sites requests

If you ever want to see all the past and present, and pending SharePoint access Site Requests, this is how you do it.

1. Gear Icon > Site Information
2. Click on View all site settings
3. Under the Users and Permissions section, click on Access requests and invitations
4. From the page that will appear, you will be able to see pending requests, invitations sent to external users (more on this below), as well as the history of site access requests

View Status of invitations sent to external users

What I also really like about this page above is that it allows you to view the status of pending invitations sent out to external users. So if you shared your site externally and wondering if external users accepted the invite or not, this is the page to view this on!

SharePoint access Site Requests and Group-connected Team Sites

It is also very important to note what is actually happening to the site permissions when you accept the user request to access the site, as this might lead to some unintended consequences. Let me explain.

When you Accept a given access request, then navigate to Site Permissions (Gear Icon > Site Permissions), you will see the users automatically added to the SharePoint Site Members Group (those with Edit role)

Of course, you can change their role to Visitor or remove them altogether if necessary. However, this behavior can also lead to confusion and unintended consequences if your SharePoint site is connected to a Microsoft 365 Group (i.e., the site is part of Microsoft Teams).

One would expect that by requesting access to the site, they become a member of the whole Microsoft 365 Group (Teams, Outlook, Planner, etc.). But that is not the case. They are just given access to the site itself only. If you check the group membership, they won’t appear there.

So if you would like to add those users to the group itself and give them access to Teams, etc., you would need to add them as members of the group. By the way, I explained these two different models of security for a group-connected site in this article.

The post How to manage SharePoint access Site requests appeared first on SharePoint Maven.

One of the biggest advantages of using a cloud platform like SharePoint is the ability to share documents with others by sharing links instead of attachments in the email. There are lots of advantages to this, all of which I documented in an earlier post. However, there is also another great set of features related to sharing when you share Word documents. So today, I want to explain a few different ways/modes available when sharing Word documents in SharePoint and OneDrive.

Link Types vs. Permissions modes

To clarify, in this article, I am not talking about whom you are sharing with, in other words, the different types of links you see when you try and share documents (i.e., Anyone with the link, People in your organization with the link, People with existing access, Specific people). I explained those types of links and the difference between them here. Instead, this article focuses on what the recipient will be able to do with the shared document (i.e., View or Edit).

Can View

When you share a Word document or any other type of Document (Excel, etc.) – you can choose between the Can view and Can edit type of mode. The View mode will just allow the user to:

• Read a document
• Download a document

What happens to the Version History in the View mode?

Since the view mode does not allow the user to edit documents, versioning will remain unchanged, and no other versions will be created.

Can Edit

Edit mode will allow the recipient to also make changes to the document. As with View, this option is available for all file types (Excel, PowerPoint, etc.) To summarize, the Edit mode will allow the users to:

• Read a document
• Download document
• Edit document
• Delete document

What happens to the Version History in Edit mode?

Since the recipient will have edit capabilities, there will be a change in versioning. Every time the doc is changed, another version is created. Many times when the user does not even make the changes, the version can still be created (i.e., the recipient just moved the cursor or added space somewhere inadvertently). This will register another version even if no intended changes have occurred.

The recipient’s changes will immediately be made to the document, and that change will be the latest and greatest from that moment on.

Can Review

This permission level is only available when sharing Word documents (not Excel or PowerPoint). When this mode is chosen, the Word document will be shared with the recipient in the Review mode. That is when any changes the recipient makes will become marked-up suggestions and not the actual changes until the document owner approves or rejects them.

Experience for the recipient

When the recipient changes the document shared with them in Review mode, all the changes become the suggested markups.

Experience for the document owner

The owner of the document will see those changes and be able to either approve or reject them inside of the document or via the Review panel.

What happens to Version History in the Review Mode?

There will be two more versions created as a result. One for suggested changes made by the recipient in the Review mode and one for the Owner of the documents once the changes are either accepted or rejected.

The post 3 ways of sharing Word documents in SharePoint and OneDrive appeared first on SharePoint Maven.

It would seem like the simplest thing in the world: show results in the PnP Modern Search Results Web Part in alphabetical order. My wanting to do this led to multiple conversations with my search guru Mikael Svenson (@mikaelsvenson) and the uncovering of some really useful variants on RefinableString in the SharePoint Online Managed Properties.

The new(ish? – it’s not clear how long they have been there) pre-created Managed Properties which are variants of RefinableString are now documented in Manage the search schema in SharePoint – SharePoint in Microsoft 365 | Microsoft Learn. Until I offered some updates recently, these variants weren’t in the article. I’m not sure I’d ever found this article before, but it seems to be the canonical list of Refinable Managed Properties, along with a lot of useful information about the Search Schema.

The new (to me, anyway) ones are in the last four rows of the following table in that article:

Managed property type	Count	Multi	Query	Search	Retrieve	Refine	Sort	Managed property name range	Notes
Date	10	–	Query	–	–	–	–	Date00 to Date09
Date	20	Multi	Query	–	Retrieve	Refine	Sort	RefinableDate00 to RefinableDate19
Date	2	–	Query	–	Retrieve	Refine	Sort	RefinableDateInvariant00 to RefinableDateInvariant01	*
Date	5	–	Query	–	Retrieve	Refine	Sort	RefinableDateSingle00 to RefinableDateSingle04
Decimal	10	–	Query	–	–	–	–	Decimal00 to Decimal09
Decimal	10	Multi	Query	–	Retrieve	Refine	Sort	RefinableDecimal00 to RefinableDecimal09
Double	10	–	Query	–	–	–	–	Double00 to Double09
Double	10	Multi	Query	–	Retrieve	Refine	Sort	RefinableDouble00 to RefinableDouble09
Integer	50	–	Query	–	–	–	–	Int00 to Int49
Integer	50	Multi	Query	–	Retrieve	Refine	Sort	RefinableInt00 to RefinableInt49
String	200	Multi	Query	–	Retrieve	Refine	Sort	RefinableString00 to RefinableString199
String	40	Multi	Query	–	Retrieve	Refine	Sort	RefinableStringFirst00 to RefinableStringFirst39	*
String	10	Multi	Query	–	Retrieve	Refine	Sort	RefinableStringLn00 to RefinableStringLn09	**
String	50	–	Query	–	Retrieve	Refine	Sort	RefinableStringWbOff00 to RefinableStringWbOff49	***
String	50	Multi	Query	–	Retrieve	Refine	Sort	RefinableStringWbOffFirst00 to RefinableStringWbOffFirst49	*, ***

* Mappings to crawled properties – Include content from the first crawled property that is not empty, based on the specified order.
** Language neutral word breaker
*** Complete Matching

As you can see, each of the additional RefinableString* Managed Properties has something a little different about it, as indicated in the Notes.

Need to know more? Feel free to ask your questions in the comments.

Resources

• Manage the search schema in SharePoint – SharePoint in Microsoft 365 | Microsoft Learn
• How Do Site Columns Become Managed Properties – Thus Available for Search? | Microsoft Learn
• Introduction – PnP Modern Search (v4) (microsoft-search.github.io)
• Sort by Filename · Issue #2351 · microsoft-search/pnp-modern-search (github.com)

This is a quick tip about a SNAFU which caught me up today. I got to do a “Doh!” in front of a client, which is always fun. Hopefully this will save you the same embarrassment.

Filtering News pages based on some metadata applied to the pages is a thing, and has been for a good, long time. I knew it should work, and pretty easily at that.

When I was on the call, I had added a metadata column to the Site Pages library. Simple. I went and put the page with the News Web Part into edit mode and looked in the Filter section for Page properties. No joy. Instead I was seeing:

Managed Properties are awesome, and I set them up all the time so I can build search-driven solutions, usually with the PnP Modern Search Web Parts, which, as I’ve said before, are the bees knees. But I knew there should be an option to filter based on Page properties instead. Had something changed? Was it better? I wasn’t sure.

I fired up my MVP communication channel and asked if things had indeed changed. As I expected, Susan Hanley (@susanhanley) responded almost right away.

Look to see what the Source is for News. When it is a single site (i.e., the site you are on), you can filter using Page properties. When you are selecting news from multiple sites, you will not see the Page Properties option – just Managed property.

Doh! I hadn’t even though to check that setting! A simple change at the top of the News Web Part properties to use This site as the source, and Page properties was back where I expected it.

This makes sense if you think about it. The Page properties in Site Pages libraries probably wouldn’t be consistent across multiple sites, so Managed properties makes more sense. Within one site, the Site Pages library is a single source, so has to be consistent with itself.

I do think there could be some in-Web-Part assistance for this with a slightly better UI, though. Maybe just an info bubble like the Enable audience targeting section right below it?

---

As you might expect, Greg Zelfond (@gregoryzelfond) has a great post about all this if you want to understand it better:

How to manage categories of news using custom metadata – SharePoint Maven