You build an OData filter query on a SharePoint list, you want to find every item assigned to a specific person, and the natural thing to write is something like AssignedTo/Email eq 'manuel@manueltgomes.com'. The query runs, returns nothing, and you spend twenty minutes wondering whether the filter is wrong, the column is wrong, or the user just doesn't have any items assigned.

The filter is wrong, but not in the way you think. The attribute is EMail, with a capital E and a capital M. That's not a typo in this article, and it's not a typo in Microsoft's documentation either. Let me walk you through why.

The column is literally called "EMail"

When SharePoint exposes a user object through a Person or Group column, the email attribute on that object has the internal name EMail. Both the E and the M are uppercase. That's the actual internal field name on the hidden User Information List that every SharePoint site keeps, and OData reads from internal names, not display names.

This trips people up because almost every other system calls this field "email" or "Email." SharePoint went its own way long before OData filters were a common thing, and the casing stuck. Microsoft has never changed it because changing internal names breaks every solution that ever referenced them.

So when you see EMail in an OData filter query, it isn't a quirk of one example you copied from a forum, it's the only spelling that works.

Using EMail in a filter

A Person or Group column doesn't hold a string, it holds a user object with several attributes. OData can't compare an object directly, so you reach into one of its attributes with the slash syntax.

The pattern looks like this:

AssignedTo/EMail eq 'manuel@manueltgomes.com'

That goes into the Filter Query property of the SharePoint Get Items action. AssignedTo is the column's internal name on the list, EMail is the attribute on the user object, and the value goes in single quotes because email is a string.

If you'd rather match on display name, the attribute you want is Title:

AssignedTo/Title eq 'Manuel Gomes'

Id works too, when you have the user's SharePoint ID on hand:

AssignedTo/Id eq 42

No quotes on Id, since that one is numeric.

Why "Email" silently returns nothing

Here is the part that wastes the most time. If you write AssignedTo/Email (capital E, lowercase m) or AssignedTo/email, SharePoint doesn't always throw a hard error. In some flows you get an "expression is not valid" message, in others you just get an empty array back, like there are no matching items.

The empty-array case is the dangerous one. Your flow looks like it ran fine, your "SharePoint Get Items" action succeeded, and the next action that depends on those results just does nothing. You only notice when a user complains that their items aren't being processed.

When a Person filter returns zero rows and you're sure the data is there, the first thing to check is the casing on EMail. It's almost always that.

The same rule applies to the column name

While we're talking about case sensitivity, OData filters use the internal column name, not the display name you see in the SharePoint UI. If someone created a column called "Project Manager," its internal name is likely Project_x0020_Manager, and Project Manager/EMail eq '...' won't work, you need Project_x0020_Manager/EMail eq '...'.

The quickest way to find the internal name is to open the list, go to List Settings, click the column, and look at the Field= parameter in the URL at the top of the browser. That value is exactly what OData expects.

The two case-sensitive pieces are the column internal name and the user attribute (EMail, Title, Id). The operator (eq, ne) is lowercase. Mixing those up is the source of most "my filter doesn't work" support questions on the forums.

A working example end to end

Suppose your list has a column called "Owner" (internal name Owner), and you want every item owned by manuel@manueltgomes.com.

In the "SharePoint Get Items" action, set the Filter Query to:

Owner/EMail eq 'manuel@manueltgomes.com'

If you want to be safe and check that something came back before you process it, the expression on the action output looks like this:

empty(outputs('Get_items')?['body/value'])

That uses the empty function with safe navigation via the ? operator so the expression doesn't crash if body is missing for any reason. Run the flow, and you should get only Manuel's items back. If you get zero items and you know Manuel owns several, the very first thing to verify is that EMail is spelled exactly as EMail.

Final Thoughts

EMail with a capital E and a capital M is one of those SharePoint details that looks like a typo, behaves like a typo when you get it wrong, but is actually the correct spelling. Once you've been burned by it once you don't forget, and once you know it, filtering on Person or Group columns becomes routine. The pattern is always the same: <InternalColumnName>/EMail, <InternalColumnName>/Title, or <InternalColumnName>/Id, with quotes around strings and no quotes around the ID. Stick to internal names, mind the casing, and the filter will do what you expect.

Photo by Le Vu on Unsplash