Office 365 Security & Compliance Center eDiscovery – Part 2: Condition Cards: Sender, Recipients, & Participants and Content Types

Office 365 Security & Compliance Center eDiscovery – Part 2: Condition Cards: Sender, Recipients, & Participants and Content Types

This entry is part 2 of 4 in the series Getting the most out of Office 365 Search
4.7/5 - (3 votes)

This is the second in a series of posts focusing on helping you get the most out of Office 365 Content Search and eDiscovery.


Over the posts in this series, I’m going to go over the following concepts:

In this exciting edition of “eDiscovery the Aaron way,” we’re going to tackle some of the basics of Condition Cards.

What is a Condition Card?

You can think of condition cards widgets that can be used to filter and refine your query.

When you first launch the eDiscovery or Content Search interfaces, you’re presented with the Keywords condition card.  You can just start typing stuff in there.  We’ll dig more into the special functions of the Keywords condition card in the next post, but suffice it to say, it’s pretty powerful and allows you to wield the phenomenal cosmic power of KQL search.

If you’re not up to snuff on KQL, don’t worry–Condition Cards were made for the rest of us.

You can activate the additional conditions cards by selecting + Add conditions in the search interface:

Once you’ve selected that option, you’re presented with a list of conditions you can add:

Conditions are grouped into three categories:

  • Common
  • Emails
  • Documents


Conditions that are labelled with Common are mapped across all content types in Office 365.  Conditions that are marked as Emails or Documents are only applicable to those respective types of content. What do I mean?

Common conditions such as Date or Size apply to everything, since everything has a size value and is timestamped.  For example, you can use the Date common condition to apply to SharePoint or OneDrive documents that were created on a date, or in place of the Received condition when searching email.

Here’s a sample of using the Date condition scoped against an entire Office 365 tenant:

You’ll notice the highlighted item has a document-looking icon, indicating the content was an object of some sort (read: not an email) located in SharePoint or OneDrive for Business.  You can see from the original list url path that it indeed was located in SharePoint Online.  The item above it has an envelope icon, indicating the result came from email.

If you back one step out by selecting Back to saved searches, you can see the structure of this query is (c:c)(date<2020-03-15)Fun fact: (c:c) indicates that the search terms are connected with the logical AND operator.  By placing a (c:c) at the beginning of a query string, you are telling the search engine to AND all of the conditions together.


While the common conditions will apply across any workload, the specific Emails and Documents conditions will only apply to Exchange and SharePoint locations, respectively.  If you update the previously created search to the email type-specific condition Received (using the same date configuration parameters for location), you would expect to see only email, since it’s a property related to email.

However, this currently is not the case. I inquired about the behavior, and if you use a condition that doesn’t apply to a particular content type, *all* content in the data sources is returned. 

If you are using more than actual keywords in your search, be sure to select conditions that only apply to the content storage location you have selected.  This may mean you need to run multiple searches with similar criteria.

The messaging specific condition cards include:

  • Message kind – references the item category (big bucket) of a message.  Valid types include contacts, docs, email, externaldata, faxes, im, journals, meetings, microsoftteams (which returns items from chats, meetings, and calls in Microsoft Teams), notes, posts (typically, items made in public folders, but can also include custom outlook form types), rssfeeds, tasks, voicemail
  • Particpants – anyone who is on the To, Cc, or Bcc line of a message
  • Type – this is a more specific type of categorization of a message, and is called itemclass in other contexts.  This can be used to search both specific item class types (such as IPM.Activity (Journal entries) as well as third-party imported data.
  • Received – date an item was received
  • Recipients – individuals who received an email message.  This condition covers all recipients located in To, Cc, or Bcc fields.
  • Sender – sender of a message
  • Sent – date an email was sent
  • Subject – The subject of an email message.  It’s important to note that subject is keyword-based, so if you’re looking for a particular phrase in a subject, you’ll need to enclose it in quotes (“phrase to find”).
  • To – Similar to recipients, you can find who a message was sent to. This condition only looks at the To field.


Just like email has conditions particular to it, so do documents.  The Documents conditions can be used against content stored anywhere in SharePoint and OneDrive for Business, including Office 365 Group and Team SharePoint sites.

The document-specific condition cards include:

  • Author – who created a particular document.  This is indexed from the author field of a document.  For example, if Robert Smith creates a document in Excel and then emails it to Sally Jones, who uploads it to SharePoint, search will look the retained metadata for the author (Robert Smith).  You’ll normally use the display name of a user, since that’s the value that normally will be saved in the Author property of a document.
  • Title – Just what it says it is.  If you need a particular phrase, put it in quotes.
  • Created – The date a document item was created.  This is not pulled from document metadata.  This is the date the file was created in or uploaded to SharePoint.
  • Last Modified – The date a document was last edited or modified.

And now that you’re familiar with type types of conditions, let’s go see some examples of how they work!

Sender, Recipient, & Participants

One of the most common searches you’ll perform (next to keywords, which we covered in the last post), is focused on a particular sender, recipient, or a group of participants.

Here’s what they look like and how to use them.

Sender or Recipient

These are literally just like they sound.  You put a name or email address in the condition card.  Sounds easy enough, right?  We’ll look at using the Sender condition card (Recipients works exactly the same way).  As you saw above, Sender looks at the From line, Recipients looks at To, Cc, and Bcc.

  1. Create a new search.
  2. Click + Add conditions.
  3. Select Sender and click Add.
  4. Start typing a name to auto-filter the list. Select the appropriate name (if they’re a member of the Global Address List) or enter an email address manually.  Note: while you can use quotes when adding a sender value as a keyword condition using direct KQL, quotations are not allowed when using the Sender condition card.

  5. Review the results and refine your query as necessary.


Participants works mostly like Sender and Recipients–add the condition, select names from the GAL or enter email addresses manually.  Participants looks at Sender/From as well as To, Cc, and Bcc.

  1. Create a search.
  2. Click + Add conditions.
  3. Select Participants and click Add.
  4. Start typing a name to auto-filter the list. Select the appropriate name (if they’re a member of the Global Address List) or enter an email address manually.  Note: while you can use quotes when adding a participants value as a keyword condition using direct KQL, quotations are not allowed when using the Participants condition card.
  5. Review and adjust filter as necessary.

If you’re paying attention, you’ll see that I used both Contains any of and Equals any of in the screencaps.  They function similarly, but differently.  Contains is a substring match, while Equals is an exact match.  It doesn’t make too much difference (in my experience) on these particular condition cards, but if you were to construct a raw KQL query, they would work differently.

If you select multiple particpants and use the Equals any of operator, the query that gets constructed looks like this:


If you’ll remember from earlier, that means is equivalent to saying:

( AND (

Content Types

There are some additional conditions that are very useful here for refining the type of search being performed.  The two that we’re going to focus on are Message kind and Type:

Message Kind

The Message kind condition card is a broad condition that lets you specify email content by the message types.  Valid values are:

  • contacts
  • docs
  • email
  • externaldata
  • faxes
  • im
  • journals
  • meetings
  • microsoftteams
  • notes
  • posts
  • rssfeeds
  • tasks
  • voicemail

These big-bucket item types let you look for the content that matches a message category that may live in a mailbox (whether it’s a user mailbox, Office 365 group mailbox, or a team).  Here are a few examples:


Using the content type of im with message kind will show you 1:1 or peer-to-peer instant message chats that have been saved in a user’s mailbox as well as chats that have been posted in a channel conversation.  In this first example, i searched for IM in a particular mailbox.  The first screenshot reveals the saved message in the mailbox; the second screenshot shows the Microsoft Teams user interface with that same message.

If you include a Microsoft team in the “messages” location for a search, you’ll see that IM also shows channel conversations.


Another type of kind is meetings.  The meetings kind shows calendar items of all types.  You can see it below:


If kind was the big bucket item, type is the much, much smaller bucket.  It has the capability of being incredibly precise.  When we looked at the previous example for kind:meetings, its granularity was crude, showing everything that is some sort of calendar appointment.  When we look to refine with type, there are a ton more options displayed on the condition card:

The condition card Type allows you to refine on an object’s itemClass, which is a very precise way of identifying the specific purpose of an object.  Whereas kind:meetings selects standard calendar appointments, meetings, or anything that gets added to a calendar, you can get much more specific with type–drilling down to the exact type of calendar item: appointment, meeting, meeting cancellation, meeting request, and more.

In this example, I wanted to look specifically for meeting requests that were sent to a user’s mailbox:

By adding the Type condition card and selecting Meeting requests, I can create a very specific search.


  1. When starting to use conditions I haven’t used (or haven’t used in a while), I’ll typically add them using condition cards just to get the property name and syntax right.  I’ll then go back to the list of searches and copy the KQL query into Notepad and begin editing the query to make it more specific.
  2. Depending how you add conditions (both cards and values) in the search query window, you may get different search results than you expect.  For example, if you use the keyword list, those conditions are connected by a logical OR, while adding other conditions are connected by logical ANDs.  Reviewing and editing the query directly is the best way to ensure you’re conducting the most precise and accurate search.
  3. Typically, the goal of content search or eDiscovery is to find the most responsive data.  You do this by creating the most precise search possible with the search conditions, keywords, terms, and other properties necessary to scope to the tightest boundary possible.


That’s a wrap, folks–feel free to leave comments or questions here (or on any of the other blog posts in this series).

Series Navigation<< Office 365 Security & Compliance Center eDiscovery – Part 1: Overview of Content Search and Core eDiscoveryOffice 365 Security & Compliance Center eDiscovery – Part 3: Phrases and Grouping AND OR’ing (Oh, my!) >>

Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese. View all posts by Aaron Guilmette

Exit mobile version