Selecting a Unique Identifier

Don't Rely On Email Addresses

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:

1. DON'T use email addresses to identify a user. 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.
2. DO use ids to identify a user. Even if a Person's email address changes, their Edlink id won't change. The Edlink id is tied to their account within the source data provider.

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 for user matching. Relying on the stable Edlink id ensures that regardless of which email alias is used for login or returned by the IdP, your application correctly identifies the user.