This post describes a scenario where you’ve added site columns and content-types to a modern SharePoint Online site, created a list and added content and once Search has indexed your content you’re expecting there to be search crawled properties available in the sites search settings pages.

Sites

• Group connected team site
• Microsoft Teams team site
• Modern Communications site

But when you go to the crawled (/_layouts/15/listcrawledproperties.aspx?level=sitecol) and managed properties (/_layouts/15/listmanagedproperties.aspx?level=sitecol) pages in Site Settings, you don’t see the crawled and auto-created managed properties that you expect.

At this point you’re probably wracking your brains trying to figure out why, verifying that you’ve done the rights steps, questioning your skills and career choices, after all this is something you’ve done many times before 😱🤯😥.

Steps

1. Created site columns
2. +/- Created Content-types
3. Created a list or library
4. Added the site columns and/or content-types to the list/library
5. Added content items and populated column data/metadata
6. Waited for Search to index your content
7. Using the OOTB site or list/library Search features confirms that its indexed your content

Well rest easy SharePointarians, turns out this is something of a known issue that has been reported and documented by other folks over the years;

• Joanne C Klein: https://joannecklein.com/2019/02/08/crawled-managed-properties-and-modern-team-sites/
• Trevor Seward: https://thesharepointfarm.com/2018/11/crawled-properties-not-created-from-site-columns-in-modern-sites/
• Asish Padhy: https://asishpadhy.com/2018/11/06/fix-for-site-column-not-showing-up-in-search-crawled-properties-in-microsoft-team-sites/

The upshot from these posts is that, this issue only affects Modern group connected sites and teams connected sites, and the resolution is to ensure that you are explicitly added to the Site Collection Administrators group — for group/teams connected sites only the Group/Team Owners group is added to the site collection administrators, not the Owners individually.

After adding yourself to the site collection administrators, the issue was resolved, you could once again see the crawled properties you expect and map them to managed properties all day long 🍻

Why is this important

Well, the issue seems to be one of visibility of crawled properties through the UI, you see, the crawled properties are actually created, and so too are the automatically created managed properties for eligible field types — https://docs.microsoft.com/en-us/sharepoint/technical-reference/automatically-created-managed-properties-in-sharepoint

So even if you can’t see them they’re still there are you can use the auto-created managed properties for Querying (search expressions) and Retrieval (showing in your search based solutions).

But, these auto-created managed properties do not support Refinement or Sorting, Taxonomy fields don’t automatically get a managed property and Date fields get automatically mapped to a TEXT managed property which is not useful for filtering or sorting.

So for these reasons (and more) you might want to map crawled properties to managed properties, RefinableString, RefinableDate etc, which you can’t do if you can’t see the crawled properties in the crawled properties UI.

Technically it’s possible to hand craft the Search Schema import files, but the XML schema for this is not documented and is pretty opaque.

Thats not the end of the story though, a short while ago (couple of weeks from the date of this post), I and my colleague also noticed this issue occurring on ordinary modern communications type sites — sites which were not group or teams connected at all.

Both of our tenants were spread across both EU & UK datacentres, apart from that there was nothing odd or unique about the sites and columns we were using — a mix of Text, Choice, Taxonomy etc.

Cue …wracking brains trying to figure out why, verifying the rights steps, questioning skills and career choices…

So after much googling and reaching out on twitter (thanks https://twitter.com/mikaelsvenson) the issue was still not resolved and a support ticket was raised with Microsoft.

Long story short (progressing MS support tickets can be painful at times 🤓) the following workaround suggested by MS Support resolved the issue for me;

Pre-reqs

1. The user account I’m using is explicitly added to the site collection administrators group
2. I’ve created site columns/content-types
3. Added content
4. Ensured search has indexed that content
5. Verified that search has created the crawled properties and auto-created managed properties by performing a POST Search Query using Postman

Steps

First pick a content item that you know has been indexed

Now Share the item using the Specific People method (I chose Allow Editing but I don’t know if that makes a difference)

Now Share the item with yourself — weird I know

Having done that, you’ll probably receive 2 emails as the Sharer and Share-ee

Now go to the list settings and re-index the list or library

Now you have to wait for search to re-index the content….

After a while, if you then return to the crawled properties settings page, magically the crawled properties appear 🎉🎉

For me this workaround only had to be done once, for only 1 piece of content, and this caused all of the crawled properties for all of my different types of content to appear — not just the crawled properties associated with the content item I shared.

So now that the crawled properties are once again visible in the UI they can be mapped to managed properties, and your search schema can be exported or built into a PnP Template.

• Photo by Ray Hennessy on Unsplash