Microsoft Dynamics 365 | Integration, Dataverse...

Import Contact-Group relationships into Dataverse using Email to identify the correct Contact?

(1) Share

Report

Posted on by Chime

153

Hi guys,

I’m migrating data into Dynamics 365/Dataverse and need some guidance, ideally with detailed steps.

I have three tables:

Contact – Contact Name, Email
Group – Group Name
Contact Group – intersection table containing Contact lookup, Contact Email and Group lookup

A Contact can belong to multiple Groups, and the email associated with the Contact can also vary depending on the Group membership.

My source Excel contains:

Contact Name | Contact Email | Group Name | Group Owner

The issue is that during the standard Excel import, Dataverse appears to resolve the Contact lookup using Contact Name. Where multiple Contact records have the same name, the relationship can therefore be associated with the wrong Contact.

What I need is:

Contact Email → find the correct Contact record → populate the Contact lookup → find the Group → create the Contact Group relationship

Could someone please provide detailed steps for configuring this correctly in Dataverse, particularly how to make the Contact lookup resolve using the email address

rather than Contact Name during the import?

Thanks,

Categories:

Dynamics 365 general

Power Platform integration

I have the same question (0)

All responses (5)

Answers (0)

Sort by

Suggested answer

11manish 1,309 Super User 2026 Season 2 on at

Like (1)

Report
Copy link

Link copied!

Use an alternate key for the Contact and Group tables, then use a Dataverse Dataflow to populate the Contact Group intersection table using those keys. Do not allow the import to resolve the Contact lookup by Contact Name.
And because you specifically said that email may vary by Group, I would first establish whether email is truly a unique Contact identifier. If it isn't, introduce a stable external Contact ID and use that as the Contact alternate key.

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Syed Aqib Raza 68 on at

Like (1)

Report
Copy link

Link copied!
The safest approach is not to rely on the Contact Name lookup during the Excel import, especially because duplicate names exist.
Use the Contact's email address as the matching key and resolve the Contact lookup before creating the Contact Group records.
A good approach is:
Make sure Contact Email in Dataverse is unique if business rules allow it. The standard Contact table already has emailaddress1, which can be used to identify the Contact.
Import/create the Contacts first and make sure their email addresses are populated correctly.
Import the Groups separately and make sure each Group can be uniquely identified by its Group Name (or another unique key).
For the Contact Group Excel data, don't directly map Contact Name → Contact lookup.
Instead, use Power Automate:
Read each Excel row.
Get the Contact from Dataverse using the email address.
Get the Group using Group Name.
Create a row in the Contact Group intersection table.
Set the Contact lookup to the Contact returned from the email query.
Set the Group lookup to the Group returned from the Group Name query.
For example, the logic becomes:
Excel row | |-- Contact Email | ↓ | Dataverse Contact | ↓ | Contact ID | |-- Group Name | ↓ | Dataverse Group | ↓ | Group ID | ↓ Create Contact Group ├── Contact = Contact ID └── Group = Group ID
For the Contact lookup, the Dataverse List rows filter can be something like:
emailaddress1 eq 'contact@email.com'
Then use the returned Contact's primary ID when setting the lookup on the Contact Group record.
For the Group:
name eq 'Group Name'
and use the returned Group ID for the Group lookup.
Also add validation for cases where zero or multiple Contacts are returned. Don't automatically create the relationship in those cases; put those Excel rows into an error/review list.
If you specifically want to use the standard Dataverse Import Wizard rather than Power Automate, Dataverse supports alternate keys for identifying records during integration/import scenarios. However, an email address should only be used as the matching key if it is genuinely unique for your Contact records.
Given your requirement that the email can vary by Group membership, I would actually avoid changing the Contact lookup's primary-name behavior. Resolve the Contact explicitly from the email in the migration process and then populate the lookup with the Contact GUID. This is much safer for your data model.

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

CU-1234529-002 169 on at

Like (1)

Report
Copy link

Link copied!

Hi @Chime ,
Good points from both 11manish and Syed above, I'd flag one thing that needs resolving first, since it directly affects the approach: you mentioned the email varies by Group membership. This is important because it means email alone can't reliably identify a unique Contact record, the same person could have different emails depending on which Group they're tied to in your source data.
Two ways to handle this:
Option A : If Contact Email is meant to be the same person's varying "context email" (not proof of a different person):
Then don't use emailaddress1 as your lookup key directly. Instead, resolve the Contact using a combination of Contact Name + Contact Email together to narrow down to the right person, or better, if your source Excel has any other stable identifier (employee ID, CRM ID, external system ID), use that as your alternate key on Contact, much safer than relying on name + email matching, which can still collide.
Option B : If different email per Group genuinely means it could be a different Contact record:
Then your matching logic should be Contact Email exact match only - no fallback to name and any row where the email doesn't resolve to exactly one existing Contact should go to your error/review list (as Syed suggested), rather than guessing.
Practically, I'd do this as a staging table approach rather than pure Power Automate row-by-row (which gets slow for larger volumes):
1. Import your raw Excel data into a staging Dataverse table (or even just a temp SQL/Dataflow staging area) with all four columns as plain text.
2. Run a Power Automate flow or a Dataflow with a lookup/join step matching Contact Email (or your combo key) against existing Contacts, and Group Name against existing Groups.
3. Flag rows with 0 or 2+ matches into an exceptions table for manual review, don't auto-create ambiguous relationships.
4. Only then bulk-create the Contact Group rows using the resolved Contact GUID + Group GUID, ideally via the Dataverse Web API bulk operations (or ExecuteMultiple) for performance if volume is high.
This avoids the standard Import Wizard's name-based resolution entirely, and gives you a clean audit trail of what matched vs. what needs manual review.

Thanks!

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

rajeshjamrodh 50 on at

Like (2)

Report
Copy link

Link copied!

Hi As suggested by @11manish , we should use Alternate Keys for the Contact and Group tables where a stable business key is available. This approach is useful when the external system does not have the Dataverse GUID and needs to identify records using business-defined unique values.
Dataverse Alternate Keys can uniquely identify records using one or more columns and can be used for integration operations such as retrieve, update, delete, and upsert.
If the required business key does not already exist, we can create a dedicated column and define it as an Alternate Key, provided the value is guaranteed to be unique and stable. We can then use this key for the required database/integration operations instead of depending on the Dataverse primary GUID.

1 people found this reply helpful.

Was this reply helpful? Yes No
Suggested answer

Travis South 67 on at

Like (1)

Report
Copy link

Link copied!

One additional point is that the data model itself is giving you a useful clue here. If the email address can vary by Group membership, that email is really an attribute of the Contact Group relationship, not necessarily a reliable identifier for the Contact.
I would keep the group-specific email on the intersection table and resolve the Contact lookup using a stable Contact identifier wherever possible. That avoids making email carry two jobs at once: identifying the person and describing how that person is contacted within a specific Group.
For the migration, a staging step is usually worth it so you can resolve and validate the Contact and Group GUIDs before creating the Contact Group records, rather than relying on the standard import lookup behavior.

1 people found this reply helpful.

Was this reply helpful? Yes No