Don't Rely On Email Addresses Alone for Day-to-Day Matching
Click here to read our blog post about why email addresses aren't a good way to match users.
In short, we recommend the following:
- DON'T use email addresses as your primary identifier for an active account. Most LMS and SIS systems do not verify email addresses for an account. This means you can't trust that whoever is logging in really owns the email address associated with their Person.
- DO use Edlink
ids to identify a user in normal operation. While a Person's email address may change, their Edlinkidstays the same as long as the source system’s ID for that person stays the same. The Edlinkidis tied to their account within the source data provider.
When Source IDs Change
Edlink never changes source IDs on its own. If the school or source system changes those IDs, Edlink creates new entities with new Edlink IDs. There is no Edlink-side migration that preserves the old Edlink ID. See Edlink Identifiers.
In that situation, applications often need a secondary match to reconnect people to existing product accounts. Prefer the most stable attributes your product already stores—commonly email and/or state ID (or another district-issued identifier)—and confirm the match with the learning application or district before cutting over.
Email Aliases vs. Primary Identifiers
It is common for institutions to provide users with email aliases (e.g., jane.doe@university.edu) that differ from their primary account identifier or "official" email on record (e.g., jxd123@university.edu).
When a user logs in via Single Sign-On (SSO), they may enter their alias into the login prompt. However, the Identity Provider (IdP) will authenticate the user and return the primary identity associated with that account to Edlink.
Edlink does not modify this data; we sync the user profile exactly as the IdP provides it. Consequently, the email address appearing in the Edlink Person object—and in your application—may match the primary identifier (jxd123@university.edu) rather than the alias the user typed (jane.doe@university.edu).
This discrepancy reinforces why email addresses are unreliable as a sole day-to-day key. Relying on the stable Edlink id (when source IDs are unchanged) ensures that regardless of which email alias is used for login or returned by the IdP, your application correctly identifies the user. Use email or state ID matching primarily when remapping after a source-ID change, not as a replacement for Edlink IDs in steady state.