As mentioned both approaches will attempt to auto-resolve the email distribution list to User and Contact records in CRM. So if you just used Track for an email that has a corresponding contact in the CRM database (matched on email address), it will auto-resolve to that contact and appear in the Closed Activity list. If on the other hand you decided to use Set Regarding to track that same email to a say a case in CRM, then this email will appear in both the Closed Activities for the case as well as for the contact it was auto-resolved to (the same would be true if you were using Set Regarding to an entity that has no relation to contacts).
It therefore goes without saying that if the "auto-resolution" functionality was somehow broken then you would get none of the above mentioned benefits. Or perhaps even worse - if you elected to "auto-create" contacts as part of the tracking functionality (see screenshot below) - if the "auto-resolution" functionality was broken, it could result in duplicate contacts entering your CRM system as the system fails to match it to an existing contact, and therefore decides to create a new contact record.
The above scenario is not only theory but something that actually was occurring in one of our installations. It is not exactly clear when the problem was introduced into the environment as the client was not using the email tracking features. Until recently that is...
After further analysis and discussions with Microsoft support it turned out that the reason the auto-tracking feature was not working was because the EmailSearch view in the CRM database was not getting updated. Probing a little deeper it turned out that the root cause of this issue was due to the fact that the "Format" on the email attributes of the contact record was text rather than email. This is not a setting that can be changed from the front end, so it's not clear how it came to be but it originated in the 4.0 environment and remained that way through the conversion to CRM 2011.
The steps for resolving this are twofold:
- Revert the field back to the Email format.
- Update the EmailSearch view for existing records
Steps for reverting the field back to Email Format:
1.
Open CRM web client as an
administrator and create a new Solution; open IE, browse to CRM, click
Settings, click Solutions and then click the new button under Solutions.
2.
Within the new Solution window fill
out the form as below and click the Save button. Display Name: Contact Name:
Contact Publisher: Default Publisher for CRM2011. Version: 1.1.1.0
3.
Now click on Entities within the
Solution and then click the Add Existing button.
4.
Check the Contact entity and then
click OK.
5.
When prompted about the missing
components select “No, do not include required components” and then click OK.
6.
Click the Save button.
7.
Now click the Export Solution
button.
a.
Click Next unless you have not
published customizations. Click Publish Customizations first and then click
Next.
b.
You will be prompted about other
missing components. Just click Next to ignore these as we will be importing
this Solution right back into the same organization.
8.
At the next window do not select any
Settings and just click next.
9.
Since this will be an unmanaged
package so just leave the current option “Unmanaged” selected and click Export
button.
a.
You will now be prompted to save the
file. Just save it to the desktop of the CRM server.
10.
Go to the desktop of the CRM server
and open the newly created zip file titled Contacts_1_1_1_0.zip.
a.
Extract the file customizations.xml.
b.
Open the customization.xml file with
an XML editor.
11.
Press Ctrl+F and search for the
string EmailAddress1.
a.
Under EmailAddress1 locate the
element “<Format>text</Format>”.
b.
Within in the element change the
word text to email. Save and close the file.
12.
Now place the modified
customization.xml file back into the zipped solution Contacts_1_1_1_0.zip.
13.
Back in CRM Solutions click the
Import button.
14.
Browse to the location of the
Solution file Contacts_1_1_1_0.zip and then click next.
15.
Click Next to import the Solution.
Update the EmailSearch view:
One way to go about updating this view is to "touch" the email for all contact records. For example, you could do this by creating a workflow that copies the email to a temporary field and then in a subsequent step copies it back. You could then apply this workflow to all your contact records.
If your contact database is large the above approach might not be practical and you may want to use a script instead. Below is a script that can be used to update emailaddress1 on the contact record. This script is not supported so please use and update at your own discretion.
DECLARE @id
uniqueidentifier
DECLARE @email nvarchar(100)
DECLARE @entitycode int = 2 -- Contact
DECLARE @columnnumber int = 42 -- Email Address 1 (45 for emailaddress2, 47 for
emailaddress3)
BEGIN
declare DetailCursor cursor
for
select contactid,
EMailAddress1
from Contact
where emailaddress1 is
not null
and ContactId not in (
select ParentObjectId
from EmailSearchbase
where ParentObjectTypeCode =
@entitycode
)
open DetailCursor
fetch DetailCursor into
@id, @email
while @@fetch_status
= 0
begin
insert into EmailSearchBase (EmailSearchId,
EmailAddress, ParentObjectId, ParentObjectTypeCode,
EmailColumnNumber)
values (newid(), @email, @id, @entitycode,
@columnnumber)
fetch DetailCursor into
@id, @email
end --while
close DetailCursor
deallocate DetailCursor
END
Your solution is perfect. Thank you very much !!!! :)
ReplyDeleteThanks for the post - it worked. Changed field type directly on the database without reimporting solution. It can be done altering MetadataScheme.Attribute table where you need to change AttributeTypeCodeId to "email" in the corresponding field.
ReplyDelete