Managed Properties
Common Use Cases
- Search filters by metadata: map a Department or Document Type column to a refinable property so users can narrow search results by it
- KQL property queries: enable precise searches like DocumentType:Policy in search boxes, verticals, and web parts instead of keywords alone
- Highlighted Content web part: roll up pages and documents across sites using managed property based custom queries
- Search verticals: scope a vertical’s KQL query with managed properties so each tab returns only the right kind of content
- Sorting beyond relevance: make dates, numbers, or names sortable so search driven views can order results predictably
- Title and value control: map several crawled properties to one managed property and decide which value wins through mapping order
Benefits
- Metadata becomes findable: the site columns your users already fill in turn into precise search targets
- Automatic for site columns: SharePoint auto generates a crawled property, a managed property, and the mapping whenever it crawls a site column
- Tenant wide consistency: a mapping made at the tenant level serves every site collection with identical behavior
- Powers the whole search stack: verticals, filters, result layouts, and content roll ups all read from managed properties
- No code required: everything is configured through the search schema rather than custom development
- Generous built-in inventory: hundreds of reusable refinable properties cover string, date, integer, decimal, and double types
Details
- Feature Category: Search & AI
How It Works
- Crawl extracts properties: every column and metadata field becomes a crawled property, with site columns typically prefixed ows in the schema
- Mapping feeds the index: only crawled properties mapped to a managed property contribute content and metadata to the search index
- Attributes shape behavior: searchable, queryable, retrievable, refinable, sortable, and multi-valued settings define what each property can do
- Auto generated entries: properties created automatically from site columns display in grey, and changing their settings converts them to regular managed properties
- Reindex to apply: changes take effect only after content is recrawled, and a list or library can be flagged for reindexing on the next crawl
- Configurable details: each property carries a name and alias for reusing built-ins like RefinableString00, a type, crawled property mappings that pick all values or the first non empty one, and tokenization options that improve matching for part numbers and identifiers
Limits and Nuances
- Custom types are limited: managed properties created in SharePoint Online can only be Text or Yes/No and cannot be refinable or sortable
- Reuse instead of create: refinable needs are met by aliasing unused built-ins like RefinableString00 through RefinableString219 and the RefinableDate, RefinableInt, RefinableDecimal, and RefinableDouble ranges
- Nothing happens until recrawl: mappings are not retroactive, so request reindexing of affected lists and libraries after schema changes
- Case sensitivity: auto generated managed properties must be referenced with exact casing in REST and KQL queries or they return nothing
- Refinable targets the older results page: the refinable attribute affects the legacy search results experience, while modern Microsoft Search filters are configured separately
- Alias carefully: an alias that matches an existing property name takes precedence in queries and can break experiences relying on the original
- Deleting is disruptive: removing a managed property breaks queries, query rules, and web parts that reference it
- Excel numbers are skipped: purely numeric values in Excel files are not indexed, though strings like PO123456789 are
Common Questions About Managed Properties
What is a managed property in SharePoint?
A managed property is a field in the SharePoint search index. During crawls, SharePoint extracts content and metadata as crawled properties, and the ones mapped to managed properties become part of the index. Each managed property carries attributes such as searchable, queryable, retrievable, refinable, and sortable that control exactly how users and web parts can work with that piece of metadata in search.
What is the difference between a crawled property and a managed property?
A crawled property is raw material: every column and piece of metadata the crawler discovers becomes one automatically. A managed property is the refined, indexed version that search actually uses. Content only enters the search index through that mapping, so a column users cannot find in search is usually a crawled property that has not been mapped or has not been recrawled yet.
What do searchable, queryable, retrievable, refinable, and sortable mean?
Searchable puts the property’s content into the full text index, so a plain keyword query matches it. Queryable allows property restrictions like author:Smith. Retrievable lets the value display in search results. Refinable allows the property to act as a filter, and sortable allows results to be ordered by it. Refinable and sortable are only available on built-in managed properties in SharePoint Online.
What is RefinableString00 and why would I rename it?
SharePoint Online does not allow creating brand new refinable or sortable managed properties, so Microsoft ships hundreds of pre created ones, including RefinableString00 through RefinableString219 plus RefinableDate, RefinableInt, RefinableDecimal, and RefinableDouble ranges. You pick an unused one, give it a friendly alias such as DocumentType, and map it to your column’s crawled property. After a reindex it behaves like a custom refinable property.
Why is my new managed property not returning results?
Schema changes only apply to content crawled after the change, so existing items keep their old index entries until they are recrawled. Requesting reindexing of the affected list or library queues all its items for the next crawl. Also check that the mapping points at the right crawled property, that the property is queryable, and that the casing matches, since auto generated properties are case sensitive.
Should I configure managed properties at the tenant or the site collection level?
Microsoft recommends mapping built-in refinable properties at the tenant level, because one mapping then serves every site consistently and performs better long term. Site collection level changes are best for experiments scoped to a single site. When Greg Zelfond builds LookBook 365 intranets, search columns like Document Type are mapped once at the tenant level so refiners behave identically across every department site.