Editorial
Microsoft Search has been in development for several years, with new features being added to make it increasingly more useful as part of Microsoft 365. So how is Microsoft Search performing right now? What are its benefits and limitations — and how can you make the most out of its capabilities?
Microsoft Search has come a long way since its first iteration. The service, initially released as part of the Office 365 suite, was designed to enable users to quickly navigate through their documents and emails. Over the years, Microsoft has continued to develop and refine the feature, making it increasingly powerful and user-friendly.
Today, Microsoft Search is integrated across the Microsoft 365 suite, including Office 365, SharePoint, Teams, OneDrive, Stream, etc. as well as Word, PowerPoint and Excel.
Graph Connectors and Federated Connectors
Previously, the only way to connect to Search in Office 365 was to create a hybrid search deployment, which required setting up a SharePoint on-prem farm and connecting it to the content source. Today, if you want to build a cross-systems enterprise search application, we can connect third-party systems to Microsoft Search directly.
Related Article: The Rise and Fall of Microsoft Search
There are a couple of ways to connect external sources to Microsoft Search:
- Out-of-the-box Microsoft Graph Connectors: these are connectors developed by Microsoft, which have a limited set of functionalities. Currently, there are Graph Connectors available for repositories such as Salesforce, ServiceNow, file shares, etc. without the need for an on-prem SharePoint to crawl the content.
- Custom Graph Connectors: Since the set of out-of-the-box Graph Connectors is limited in both number and functionality, you might need to develop custom connectors or to third-party Graph Connectors from various vendors.
- Federated Connectors do not index the content of the source, but rather use a remote, federated search index to retrieve the results. As of today, we can create federated connections to Microsoft Dynamics and Azure Cognitive Search (in preview).
Licensing
To use Graph Connectors to index items to Microsoft Search , you’ll need to purchase "index quota" licenses by the number of items in the index. You can purchase extra Graph Connector capacity in the subscription administration page of your tenant. Microsoft 365 E5 licenses and Viva Topics licenses also include an entitlement of 500 items of index quota per licensed user.
Limitations and Boundaries
Although we can significantly extend the value of Microsoft Search with Connectors, there are also a couple of important limitations and boundaries to consider:
- Each tenant can create up to 30 connections.
- Each connection allows up to 5 million items.
- Overall tenant limits are up to 50 million items (If you need higher capacity on your tenant, you can connect Microsoft and request higher capacity for Graph connectors.)
Cross-System Permissions
Correct permission management is important in search connectors because it ensures that only authorized users have access to data.
Whether you use an out-of-the-box connector, develop your own or purchase a third-party connector, always consider the permission considerations, including not only unique permissions, but also group memberships as well as custom security features (e.g. field-level access to data in the source system).
Related Article: Microsoft Viva Topics and SharePoint Syntex — Better Together
Displaying Connector Search Results
The good news is, we can use custom Result Types to customize how the connector results are displayed on the Microsoft Search UI. However, there are some limitations.
As of today, connector results are displayed in separate clusters (result block) on the main "All" search vertical in Microsoft Search, and/or they can be displayed on a separate vertical. They cannot be interleaved with SharePoin or OneDrive results yet, although Microsoft says it is beginning to roll out this feature. ).
The Scope of Search
Microsoft Search provides a more or less unified user experience across the platform. The approach is that search is always context-sensitive — depending on where the user runs the query from, the results might vary.
- On the SharePoint Home and Microsoft 365 Home, the scope is the whole tenant (cannot be changed).
- On a SharePoint site, the default scope is that particular site (can be changed),
- On a SharePoint hub site, the default scope is that particular hub and the associated sites (can be changed).
- In a list or document library, the scope is that particular list/document library (cannot be changed).
- In OneDrive, the scope is all documents in OneDrive and SharePoint that the current user has access to (SharePoint libraries, his/her own OneDrive files, other users' shared OneDrive files).
The default scopes do have a structure, but the outcome can still be confusing to end users when it's not clear what results they can expect where. It's not enough to enter the query to the (otherwise unified) search box’ the user also needs to know where they are and what to expect in that specific context.
Customizing the Search Results Page
After a long wait, it is finally possible to customize the Microsoft Search results page. We can update the existing verticals, add custom verticals, apply filters and also define custom Result Types. These all are important to be able to deploy a real enterprise search solution.
Limitations and Boundaries
Having powerful search filters (refiners) is an important requirement for many. In Microsoft Search, filters can be Text and Date type values — however, it is not possible to create numerical filters, even if filtering for a range of numbers would be a requirement.
If the numerical property is one that has a well-defined set of values (e.g. year), we can map it to a Text refinable property, and use it with separate filter values for each year (2023, 2022, 2021, etc.). But in this case, we cannot filter for a range, obviously, as thanks to the mapping, these values are considered to be text.
Another limitation is related to the Result Types. We can define how search results should be displayed by creating custom Result Types. Above, I mentioned connector results — however, it is also possible to create custom Result Types for list items and documents in SharePoint and OneDrive. Here are all types that can be displayed in a custom way:
- Connector items
- SharePoint list items
- SharePoint pages
- SharePoint sites
- PDF documents.
One key absence from the list is documents in Office file formats (.docx, .pptx, .xlsx and so on). We don’t know why, but we cannot define custom Result Types for Office file formats if these files are stored in SharePoint or OneDrive. (If they are stored in a connected system such as Service Now, file share, etc., then yes, it is possible.)
Related Article: A World of Data Is a Waste of Time Without Universal Search
Site vs. Tenant-Level Customizations
To make the picture even more complex, we can customize Microsoft Search not only on the tenant level, but also on each site. The basic rule is that site-level customizations always override the tenant-level settings on that particular site. This might be a very powerful feature, but we need to be smart again to avoid complicating the experience any more than is necessary. End users always respect consistency over complexity.
Conference
Sep
16
HR Tech Conference Las Vegas 2025
Register
Conference
Oct
27
Gartner HR Symposium/Xpo Orlando 2025
Register
Conclusions
Microsoft Search has come a long way in terms of features and capabilities in the past few years. However, as with any technology, there are some limitations and boundaries that should be kept in mind when planning to bring it to the next level. The key is to understand these limitations and plan accordingly. Microsoft Search can be a feasible and powerful tool — but only with proper planning, governance and flexibility.
Learn how you can join our contributor community.
