# Normalized Email object

**URL:** <https://forum.openreferral.org/t/normalized-email-object/741>\
**Category:** Technical\
**Created:** [September 17, 2025, 5:16pm UTC](https://forum.openreferral.org/t/normalized-email-object/741 "2025-09-17T17:16:08Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![skyleryoung](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.openreferral.org/skyleryoung/32/212_2.png) [@skyleryoung](https://forum.openreferral.org/u/skyleryoung)\
**Post date:** [September 17, 2025, 5:16pm UTC](https://forum.openreferral.org/t/normalized-email-object/741/1 "2025-09-17T17:16:08Z")

</div>

Hello everyone. This post is overdue. IN 2023 I proposed a normalized URL object: [We need a normalized `url` table in the pattern of the `phone` table](https://forum.openreferral.org/t/we-need-a-normalized-url-table-in-the-pattern-of-the-phone-table/431)

I have use cases to do the same for `email` now. For example, I have data sets where email is stored at the `location`, which is not supported today. Using either `email.location_id` or `email.link_id && email.link_entity=’location’` would solve that issue and cover many other use cases to boot.

A proposal for this seems very straight forward, and would follow the same basic patterns as the URL table.

@mrshll @MikeThacker-iStandUK @devin @bloom @sasha I formally propose we write up a proposal and discuss where this falls on our roadmap. Do I have a second? Can we add this to the agenda for our next call?

---

_[View the full topic](https://forum.openreferral.org/t/normalized-email-object/741)._