Microsoft 365 eDiscovery (formerly Office 365 eDiscovery, and now managed through the Microsoft Purview compliance portal) includes several useful features for eDiscovery and compliance matters such as email archiving, Legal Holds, and eDiscovery Search capabilities.
We run a fair amount of searches for ESI (electronically stored information) in Microsoft Purview eDiscovery and can attest it has helpful search features. But despite Microsoft continuing to build out the Purview compliance portal, Microsoft 365 eDiscovery search features have real limitations that users need to plan around, and often need to augment with other eDiscovery software and workflow adjustments.
A quick naming note before we get into it: Microsoft retired the classic eDiscovery experience, including the names “Core eDiscovery” and “Advanced eDiscovery”, on August 31, 2025. The same tiers now go by eDiscovery (Standard) and eDiscovery (Premium) inside the Microsoft Purview portal. We’ll use the current names below.
Here are four Microsoft Purview eDiscovery search limitations to be aware of, and some workarounds we use.
Four Key Limitations of Microsoft 365 eDiscovery Search Capabilities:
Not all files are indexed for searching
If you’ve ever searched emails in Microsoft Purview eDiscovery (Standard), you’ve probably noticed results often contain unindexed items, like the example below.
It’s important to understand what these unindexed (technically, “partially indexed”) items are and how to handle them, so you’re not ignoring potentially important content in your searches and exports.
Items fall into the partially indexed category for a few common reasons:
- Unrecognized or unsupported file type. Microsoft indexes a defined, limited set of file types; anything outside that list won’t be indexed. See Microsoft’s current supported file types reference for the up-to-date list, this has changed over the years, so don’t rely on an older cached list.
- Image files
- An attached file has no valid handler (an app that can open the file), most commonly image files. This is the single most common cause of partial indexing.
- Too many files attached to a single message
- An attached file is too large
- Oversized spreadsheets
- Password-protected files
- Indexing errors
When exporting data from Microsoft 365, it’s often worth including unindexed items in your export so they can be processed and searched in a more advanced eDiscovery tool. These items are often several gigabytes and, admittedly, may not contain relevant data, but you won’t know until you export and review them. (Proportionality and reasonable accessibility of ESI often factor into that decision, but that’s beyond the scope of this article.)
Once loaded into a more advanced eDiscovery platform, these items get OCR’d, made searchable through optical character recognition, so you can search and cull against your terms. That leaves you with the responsive ESI Microsoft 365 wasn’t able to index on its own.
Note: eDiscovery (Premium), included with Microsoft 365 E5 or Microsoft 365 E3 plus the E5 Compliance add-on, has more features than eDiscovery (Standard), including its own OCR and advanced indexing. But Premium still has limitations that may push you toward a more robust eDiscovery tool, including native-format-only production, no ability to process third-party data, and the keyword search limitations described below.
Keyword searches have limitations
Most eDiscovery projects, compliance matters, and internal investigations depend heavily on keywords and search queries to cull large datasets. Some matters run on a handful of terms; others run on lists of hundreds.
One real limitation: keyword list size caps differ by tier. eDiscovery (Standard) and Content Search cap you at 20 rows in a keyword list per search. eDiscovery (Premium) allows up to 180 rows. If your matter has more search terms than your tier allows, you’ll need to either break searches into batches or use Premium if you’re not already on it.
Additionally, when searching multiple keywords in a single search, the results don’t tell you which specific keyword triggered inclusion of a given item. Microsoft highlights matched keywords in document previews, which helps, but if a term is found in an indexed metadata field rather than the visible content, you’ll need to dig deeper, often by running separate single-keyword searches to isolate which term is doing the work.
Wildcard searches have limits too. (A wildcard, like an asterisk *, stands in for one or more characters so you can expand a search; searching Dav* returns “David,” “Dave,” and other words starting with “Dav.”)
In Microsoft Purview eDiscovery, you can only use prefix wildcard searches, and the prefix must be at least 3 characters. cat* or set* work. Suffix searches (*cat), infix searches (c*t), substring searches (*cat*), and prefixes shorter than 3 characters (ca*) are not supported. If your search terms need one of those unsupported formats, Purview eDiscovery search won’t get you there.
Depending on your search requirements, these limits can complicate a matter meaningfully. In some cases, it makes more sense to do a full mailbox collection and process the data in a tool with more advanced search capabilities. Before running Purview eDiscovery search on a matter, we evaluate it individually and determine the most time- and cost-effective workflow, and which platform actually fits the project’s needs.
Double collection due to lack of ability to exclude prior exported data/searches
Another limitation: Purview eDiscovery doesn’t let you use a saved search as a condition in a new search. That’s a meaningful gap, because most legal and compliance matters involve multiple rounds of collection as new information and custodians surface.
For example, if you previously exported everything that hit on “red” and later want to export everything hitting on “blue,” it’d be far more cost-effective to export only the “blue” items you haven’t already collected. Without a way to save and reference a prior search or export as an exclusion condition, that’s not straightforward.
One workaround: use the “AND NOT” Boolean connector to exclude previously exported data. Using the example above, you’d search blue AND NOT red to avoid recollecting items that hit both terms and were already exported. This only works cleanly if your date range, locations, and other base criteria match your previous export exactly.
This approach gets complicated fast with multiple search terms or varying base criteria across rounds. In more complex situations, it’s often better to export without trying to exclude via “AND NOT,” and let deduplication in a more advanced eDiscovery tool handle culling the previously exported data.
Searching takes time to execute (so plan accordingly)
Fast search execution matters more than people expect, especially when you’re iterating on term hits or running complex queries. Because Purview eDiscovery batch-processes searches, it can be slow.
Compared to dedicated eDiscovery tools, Purview eDiscovery search can take considerably longer on larger or more complex matters, and you can only preview the first 1,000 hit results. If you’re searching multiple locations or mailboxes, you need to search and select each one individually, which gets tedious fast on larger matters. If you’re under time pressure, this is often a good reason to run a broader export out of Purview and do the actual searching in another tool.
We run a lot of searches in the Microsoft Purview eDiscovery environment for clients, particularly for compliance departments and in connection with large-scale document reviews. If you want to talk through how we pair Purview eDiscovery with other eDiscovery tools to improve ESI collection and search efficiency, let us know.
Additional Articles About Microsoft eDiscovery
What Version of Microsoft 365 Do We Need for eDiscovery?
Understanding Microsoft Teams eDiscovery
