The reason it's EMail and not Email or email in Power Automate

A little while ago I wrote about the capital M that breaks your SharePoint Person column filter, where the whole point was that the email attribute on a Person or Group column is spelled EMail, with a capital E and a capital M, and nothing else works. I closed that one admitting I could not find an official reason for the casing, and I asked if anyone knew.

Fair warning before we start. Microsoft has never published a single sentence explaining why it is EMail. There is no blog post, no doc note, no protocol spec that says "we capitalized it this way because," so what follows is part research work and part confirmed mechanics, and I will be clear about which is which as we go.

It could not be the most useful post that I write, but I was curious about why this happened, so I hope you like it.

Is there an official answer? No

Let me get the disappointing bit out of the way first. I went through the SharePoint field schema reference, the [MS-WSSTS] protocol documentation, the old MSDN field definition pages, and a stack of community write-ups going back to 2008. Not one of them explains the spelling. The base field tables that Microsoft does publish do not even list EMail, which tells you it lives in a corner of the product nobody bothered to document at this level.

Even the Power Automate people who use it every single day will tell you they found it by trial and error. To me this is a huge usability issue because finding something that clearly looks like a typo and learning that it's expected behavior is an issue, in my opinion.

An internal name is frozen the day it is born

Here is the mechanic that makes the whole story make sense. Every SharePoint column has two names. There is the display name, the friendly label you see in the list, and there is the internal name, the identifier the platform actually uses under the hood. You can rename the display name all day long. The internal name is set once, at the moment the column is created, and it never changes again for the life of that field.

This is a good way of doing things. An internal "thing" that doesn't change and something visible that changes depending on the person.

Microsoft's own schema reference says this in plain language: the internal name does not change for the lifetime of the field definition, while the display name can be edited at any time. In code, the internal name property is read only. There is no rename button, no setting, no supported way to change it. If you truly need a different internal name, your only option is to delete the column and create a new one.

Now apply that to a field that was created back in the first versions of SharePoint, more than twenty years ago. Whatever it was called on day one is exactly what it is still called today, because it was never allowed to change. EMail is not a spelling Microsoft keeps choosing. It is a spelling Microsoft can no longer un-choose.

Again, this is a decent way of doing things because of the complexity of the platforms and to avoid migration bugs, but migrations and upgrades exist for a reason.

But let's dig deeper.

Why the spelling looks like that in the first place

This next part is reconstruction, so take it as the most likely story rather than fact. Back when this field was created, the common way to write the word was "E-Mail", with the hyphen and a capital letter on both sides. If you read software and documentation from the late nineties and early 2000s, that spelling is everywhere. Not to age myself too much but I still remember this spelling.

Internal names in SharePoint cannot contain spaces or punctuation. So when a field labeled "E-Mail" gets its internal name, the hyphen and any spaces are stripped out, and the two capital letters that were sitting on either side of that hyphen slam together. "E-Mail" becomes EMail. It is not a grand decision, it is simply what falls out of a naming rule applied to a period-correct spelling. Microsoft was not even consistent about it across products at the time. The Active Directory schema from the same era spells the equivalent attribute "E-mail-Addresses", with only one capital, which tells you there was no single house style to follow.

So this could be a reason for why it's still EMail.

Microsoft's own rulebook says EMail is wrong

This is my favorite part. A few years later Microsoft published its .NET Framework Design Guidelines, the official rules for how identifiers should be capitalized. In the section on compound words and common terms, it gives a small table of correct and incorrect spellings. The correct forms are listed as Email and email. The form sitting in the "do not use this" column, the one explicitly flagged as wrong, is EMail.

So Microsoft's own guidance, written after the field already existed, tells developers not to spell it the exact way SharePoint spells it. The field predates the rule, the rule says the field is wrong, and the field cannot be changed to comply because internal names are frozen.

Again, complex migrations are a pain and they can bring bugs and issues, but they exist for reasons like this. Inconsistency is super dangerous for people who use these tools.

Why the casing actually bites you

None of this would matter if SharePoint were forgiving about it, but it is not.

When you query a list with an OData filter, the field names are matched case-sensitively.

The value you compare against is not, so 'manuel@example.com' versus 'MANUEL@example.com' is fine, but the field name EMail has to be exact.

Write Email or email and the platform does not see a near miss it can helpfully correct. It either throws a "field types are not installed properly" error or, worse, quietly hands back an empty result as though nobody matched. Your SharePoint Get Items action goes green, the flow carries on, and nothing else runs.

An issue for usability since we consider "empty" as "not found" while it's not the case.

Final Thoughts

All of this is speculation so if someone from Microsoft that knows their history wants to chime in I'm happy to re-write the whole article with the correct version, but my understanding is that it is something that simply was not migrated because the risks outweighed the benefits, but I'll let you be the judge based on the findings.

Photo by Daria Nepriakhina 🇺🇦 on Unsplash