Hidden Gem: Activity parties resolving technique
Views (373)
Whenever an email reached to Dynamics CRM using Server side sync or good old Email router - the sender & recipients called Activity Parties in CRM will get resolved ie. mapped to CRM records using the primary email address of every email enabled entity record.
So when arun@xyz.com is in cc line of an email which got synced in CRM as an email activity, then system will look for all the entity records in a specific order & will resolve it to every single record sharing the same email address.
But this should take a while right, how it's so quick. Bingo! EmailSearchBase - this is where the whole magic is happening. Read more
For every Activity enabled entity there will be an attribute of Email address type created if it’s not there already. So whenever a record is created on that entity there will be an entry added in Emailsearchbase table and further updates will be synchronized in this table.
In old days, though it’s unsupported we used to update this table entries in on-premise for avoiding records getting resolved in activity parties across multiple entities like system user, contact, lead which created confusion in the field but would like to maintain the record also in the system.
Sometime weird requirements will also comes like maintaining duplicate records & don’t want to merge them but neglect in Email recipients. One such scenario discussed in Stack Overflow.
So when arun@xyz.com is in cc line of an email which got synced in CRM as an email activity, then system will look for all the entity records in a specific order & will resolve it to every single record sharing the same email address.
But this should take a while right, how it's so quick. Bingo! EmailSearchBase - this is where the whole magic is happening. Read more
For every Activity enabled entity there will be an attribute of Email address type created if it’s not there already. So whenever a record is created on that entity there will be an entry added in Emailsearchbase table and further updates will be synchronized in this table.
In old days, though it’s unsupported we used to update this table entries in on-premise for avoiding records getting resolved in activity parties across multiple entities like system user, contact, lead which created confusion in the field but would like to maintain the record also in the system.
Sometime weird requirements will also comes like maintaining duplicate records & don’t want to merge them but neglect in Email recipients. One such scenario discussed in Stack Overflow.
This was originally posted here.

Like
Report
*This post is locked for comments