Identity Matching

Identity Matching controls how a sync decides whether an incoming record from a source system already exists in ExpoPlatform. When a visitor or exhibitor arrives, the sync looks up existing records using the method you've configured. If a match is found, the record is updated. If no match is found, a new record is created.

Getting this right is what prevents duplicates and makes sure updates land on the correct record.

How to configure

The setting appears as a dropdown labelled Identity in the entity's configuration.

For visitors (and team members, where the integration syncs them), the options are:

Option	Meaning
External ID (default)	Look up the visitor by the External ID provided by the source system.
Email	Look up the visitor by email address.
External ID First	Try External ID first; if no match is found, fall back to email.
Email First	Try email first, using the External ID as a guard and fallback (see the decision matrix below).

Some integrations restrict the list — CDS visitors always match by email, for example. Each integration's page notes any restrictions.

For exhibitors, only External ID lookup is supported. This isn't configurable.

Which option should I use?

External ID is the safest default when the source system provides stable, unique IDs. No risk of accidental merges from shared email addresses.
Email is simpler but can cause merges if two different attendees share an email address, or if someone registers under a different email a second time.
External ID First is useful during an initial migration where existing ExpoPlatform accounts have known emails but don't yet have External IDs populated. New records will be matched to existing ones by email, and their External ID will be recorded going forward.
Email First is designed for source systems where attendees can change their email address after registering. Plain Email matching would create a duplicate on an email change; Email First recognises the attendee through the External ID fallback and updates the stored email instead.

Decision matrix

Here's exactly what each option does for every scenario:

Option	Scenario	Outcome
External ID	External ID found	Update. If the incoming record changes the email to one used by another account, the record is skipped with reason `validation`.
External ID	External ID not found	Create.
Email	Email found	Update. If the incoming External ID differs from the stored one, it's silently adopted.
Email	Email not found	Create.
External ID First	External ID found	Update.
External ID First	External ID not found, email found	Update. Incoming External ID is silently adopted.
External ID First	Neither found	Create.
Email First	Email found; External IDs match, or either side empty	Update.
Email First	Email found; both External IDs set and different	Skip with reason `identityMatchFailed` — see below.
Email First	Email not found, External ID found	Update, including overwriting the stored email.
Email First	Neither found	Create.

Note the deliberate asymmetry: on an email match whose External ID differs from the incoming record, Email and External ID First silently adopt the incoming External ID, while Email First skips the record instead. Under Email First, the External ID is treated as the stable identity — a mismatch means "this email now belongs to a different registrant", which is something to investigate rather than overwrite.

The Email First conflict skip

When Email First finds an incoming email on an account whose stored External ID differs from the incoming one, the record is skipped with reason identityMatchFailed. The conflict shows as a notice in the sync-run report and a warning in the logs — deliberately not as an error, so it doesn't appear in the integration error report.

To resolve it, fix the data on one side: either correct the email or External ID in the source system, or update the ExpoPlatform account it collides with.

An empty incoming External ID never wipes the stored one

Regardless of the option chosen, if an incoming record carries no External ID (absent or empty), the account's stored External ID is preserved on update rather than being overwritten with the empty value.