When trying to enter a person in a SharePoint Person/Groups column you find you are able to search and select users only to encounter this error:
Your organization’s policies don’t allow you to share with these users. Go to External Sharing in the Office 365 admin center to enable it.

I found this error really hard to believe since I was using a demo tenant and had created the site and list with an admin user account and then I got this error just trying to select myself (the admin user). There’s no external accounts at play so the error just didn’t make sense.
It didn’t take too long to track down that this was occurring when I used the column option to restrict the people that could be selected in the Person/Group column to just users from a specific SharePoint group.

It’s not as simple as that though, on further investigation it seems not all groups are created equal. Restricting to some groups does work, while restricting to other groups fails. So why, what is it about restricting to some groups that makes them fail?
When you create a SharePoint site that is “groupified” e.g. a Teams site, then in addition to the 3 standard SharePoint site groups being created (Owners, Members, Visitors), a Microsoft 365 Group also gets created. It is these “groupified” groups that cause the problem when trying to restrict a people/groups column.
Here’s a walk through of the observed behaviour.
Firstly lets create a Team Site. A Team Site is a “groupified” site that will create a Microsoft 365 group. In the following walk-through the groupified Team site will be coloured blue.


Now for comparison lets also create a standard SharePoint Team site (which doesn’t create a Microsoft 365 group). We do this by selecting Other option (rather than selecting the big Team site button) on the Create a site dialog. This standard SharePoint site will be coloured yellow for the rest of the article so we can easily distinguish between the 2 sites.


Now lets take a look at the difference in how the SharePoint groups got created. The process to view this is the same for both sites. Settings | Site Permissions | Advanced permissions settings.

Both sites get SharePoint Groups created for Owners, Members and Visitors.

There is no difference between the Owners groups and Visitors groups. But let’s take a closer look at that Members group that got created in the “groupified” Team site.

So this is where that Microsoft 365 Group comes in. Rather than the SharePoint Group maintaining a list of members, it instead has the above reference that lists the underlying Microsoft 365 group. The membership is then driven by members of the underlying Microsoft 365 group which we can see below is visible from the Microsoft 365 Admin Center.

By comparison the non-groupified SharePoint site has no entries in the Members group and you can add members to this group directly in SharePoint as you would expect. Here I’ve added Alex.

The process to add a person as a Member our the groupified site is a little different. By using Group membership | Add Members, I’ve added Alex to this site as well.

After adding Alex, we can see Alex is added to the Microsoft 365 group rather than being added directly to the SharePoint group.

Group setup complete. Next lets create a list in each site and a column called Person (of type Person or Group) and configure it to only allow selection from users of the Members group.

Time to see the end result. Firstly in our standard SharePoint site (non-groupified). We can start typing Alex, get type-ahead lookup and select Alex Wilber as you would expect.

Now let’s switch to the “groupified” site and try the same thing. Here we still get type-ahead and see Alex, but trying to select Alex fails and results in the error:
“Your organization’s policies don’t allow you to share with these users. Go to External Sharing in the Office 365 admin center to enable it.”

There is also a difference in the options returned from the type-ahead search for people. The standard site only returns results of people belonging to the group the column is restricted to. The example below shows that we cannot find a result for Adele (since Adele does not belong to the Members group).

Yet on the ‘groupified’ Team site, there doesn’t appear to be any restriction on the results returned from the type-ahead. A shown below we get a result for Adele who doesn’t belong to the Members group, selecting Adele should be an invalid selection and we shouldn’t be getting presented with Adele as an option to select.

The conclusion I’ve come to is that you simply cannot use the option to restrict a Person/Group column to a “groupified” SharePoint group as this scenario is currently broken.
Thanks Cameron! I was hoping for a solution, but this fully echo’s my findings and therefore provides an answer and points me toward a solution.
LikeLiked by 1 person
Thanks for the comment Dirk. It was driving me crazy for a while until I uncovered those pesky M365 groups at play.
LikeLike
Thank you for documenting this! Yet another mickey-mouse aspect of this platform…..
LikeLiked by 1 person
Interesting – thanks for the research Cameron. I’ve not been receiving that particular error message, but my Person column in a Sharepoint “groupified” site library won’t suggest any users (“No Result Found”) when restricting the column to the M365 group. I wonder if it’s the same underlying issue.
LikeLiked by 1 person
Thanks for sharing your experience Liam, it seems like our scenarios are broken in totally opposite ways (I’m seeing everything and you are seeing nothing!). If you are technical and really want to dig deeper you can use Fiddler to watch the calls that SharePoint makes when you try to use type-ahead on the People picker field.
LikeLike