While researching the previous issue regarding Outlook Contact address sync issues I came across something interesting. That is, a pleasant, unexpected surprise...
Until now, the fields that sync between the CRM and their Outlook counterparts have been locked down. Well... that is still the case and looks like it will be the case for the foreseeable future.
However one of the common issues encountered with the above limitation is that only the primary contact address syncs to the CRM contact record (i.e. address1 to the Outlook business/mailing address). So if you wanted to sync the home address (typically address2) you were fresh out of luck... or you had to think of creative ways of maintaining such information to the description field so that it would appear there (something which I've configured for a client or two).
With CRM 2015, it appears Microsoft have finally seen the light and it appears that Address 2 fields will now sync to the Outlook home address. Of course, knowing this you may also want to consider any impact for existing organizations when they perform the 2015 upgrade.
Below is the link showing the CRM/Outlook sync mapping for CRM 2015. I have only given it the briefest of reviews so perhaps there may be other surprise within. If so, do let me know.
http://technet.microsoft.com/en-us/library/dn832089(v=crm.7).aspx
Showing posts with label Outlook Client. Show all posts
Showing posts with label Outlook Client. Show all posts
Friday, November 21, 2014
Thursday, November 20, 2014
Contact/Outlook Address Sync Issues
There appears to be an issue with syncing the contact address with Outlook under certain circumstances. Specifically this circumstance appears to occur when line 1 and line 3 of the contact address are filled out but line 2 is left blank. In such a situation the following occurs when syncing the contact:
- The contact syncs correctly to the corresponding Outlook contact record
- Outlook then immediately syncs back to the CRM contact, moving line 3 back to line 2
The following screenshots illustrates this phenomenom visually:
To re-emphasize - this boomerang update effect happens immediately i.e. in the single sync transaction that is initiated from the CRM Outlook contact. The result can be quite perplexing and unsettling as it results in the following set of circumstances:
- You notice that an update made on the contact record is continuously reverting
- The audit tells you an end user made the reversal (and it could be any end user - really depends on who performed the syncing action first)
- The audit tells you that the reversal happened within mere seconds of the update
The result is a manhunt to find the offending plugin, workflow, third party Outlook add-on that someone is using that might be behind this issue. And of course based on the analysis above all that is a red herring...
I think the reason why this occurs is because Outlook just arranges the address into separate lines rather than separate fields so that when line 2 is missing line 1 and line 3 follow one another making Outlook interpret line 3 as line 2.
I have not seen any literature about this issue although circumstantial evidence points to the fact that this issue has been around for quite some time (i.e. I seem to recall perplexing unexpected Outlook updates fitting the above description that until now I have not been able to put my finger on).
Anyway, I am able to reproduce this issue at will so it's definitely some kind of product defect.
This issue has been reported to Microsoft and at the moment I don't have a solution to this issue although at a minimum it is comforting to at least know what this issue so it can be avoided and sanity be preserved.
Thursday, December 20, 2012
Simplifying Navigation: Add to Favorites
This post is another in the series on Simplifying Navigation - it is somewhat of an "oldie" but definitely a "goodie". And I have also verified that the same issue and workaround exists using Outlook 2013.
In short, the issue is that the CRM area within the Outlook Client is somewhat buried. For example, if you wish to navigate to the Accounts, it will involve at least 3 clicks (if this area was not previously opened):
In addition to that, if you are more than likely to access a particular entity from your CRM data it would be helpful if you could separate it from the rest of the group.
And fortunately you can by simply dragging and dropping the CRM folder to your Outlook "Favorites" folder which will you give single click access to your CRM data. Much better.
As an aside, it appears that in Outlook 2013 the UI has been simplified and the icons for all the folders have been removed... including the CRM icons. Not sure if this is a long term feature or something that will be tweaked in future Office patches (I personally haven't yet decided whether I prefer it this way or not).
The issue that you may encounter is that the aforementioned drag and drop capability might not be working. And if that is the case, you need to enable this feature by running through the steps in this KB article. Or you can just download this file, unzip and double click to deploy it in your environment (this will add a single registry setting called DisabledSolutionsModule under your MSCRMClient key).
Another option that allows for a little more organization of your CRM links is to use the Outlook "shortcuts" option. In order to make this effective the first thing you should do is go to the Navigation Options and move the shortcuts up in the list so it appears in plain sight as shown.
You can then add new shortcuts to the CRM folders of your preference:
And now you can click on the shortcut to navigate to your CRM data:
In short, the issue is that the CRM area within the Outlook Client is somewhat buried. For example, if you wish to navigate to the Accounts, it will involve at least 3 clicks (if this area was not previously opened):
In addition to that, if you are more than likely to access a particular entity from your CRM data it would be helpful if you could separate it from the rest of the group.
And fortunately you can by simply dragging and dropping the CRM folder to your Outlook "Favorites" folder which will you give single click access to your CRM data. Much better.
The issue that you may encounter is that the aforementioned drag and drop capability might not be working. And if that is the case, you need to enable this feature by running through the steps in this KB article. Or you can just download this file, unzip and double click to deploy it in your environment (this will add a single registry setting called DisabledSolutionsModule under your MSCRMClient key).
Another option that allows for a little more organization of your CRM links is to use the Outlook "shortcuts" option. In order to make this effective the first thing you should do is go to the Navigation Options and move the shortcuts up in the list so it appears in plain sight as shown.
You can then add new shortcuts to the CRM folders of your preference:
And now you can click on the shortcut to navigate to your CRM data:
Thursday, June 14, 2012
Contact: Details Updated Change Log
This particular issue has been troubling me for quite some time. Every now and then, in a particular client installation, a bunch of contact records would get updated and the update would be logged in the Notes section showing the previous and current values.
Not only is this issue a little bit annoying, but when you combine this with the fact that this contact will then get updated in CRM and subequently propagated to other users' contacts folder - well then you have data pollution. First of all, the change log is unnecessary and it doesn't take long before people start blaming "CRM" or the "Outlook Client" for making these unsolicited changes. Second of all, it can in fact make changes that you don't want. Like in the screenshot above where "USA" is being replaced by "United States" where you might have certain standards and/or functionality based on the specific values that appear in a particular field. Third of all, it generates unnecessary updates that need to be uploaded and then downloaded to all other clients ("what? I didn't make changes to those contacts..."). And let's not even mention the cryptic audit comment that is written to the notes that now will appear on all contact records that get updated and if the values get reverted back to what they were previously (i.e. the correct values) this audit will appear again and again...
This particular update seemed to occur only for internal company contact records and not for external contact records. And through various tricks of the trade I was able to verify 100% that this update was not coming from CRM - rather CRM was just the conduit for propagating it as described above. But the problem was that I could not attribute this to other 3rd party software... so it was a little hard convincing the client without another prime suspect.
I finally came across the following forum posting which seemed to describe the issue I was facing to a tee: http://social.technet.microsoft.com/Forums/en/outlook/thread/8fa240c6-fb3b-48fc-b7d4-8a82919e3912
In short, from this posting 2 prime suspects emerged. The most likely one being the "Microsoft Exchange global address list (GAL) synchronization with Microsoft Outlook 2010" feature and this feature can be disabled using Group Policy as described in this article: http://technet.microsoft.com/en-us/library/ff871432.aspx. This presumably resolves the problem globally as it uses Group Policy.
The second suspect is the "Social Connector" feature that is built into Outlook 2010 and which apparently also has this change logging feature. This can be disabled on a client by client basis by navigating as shown in the screenshot below.
As can be seen, the default is "update without prompting" - a little hard to understand why it would have been designed this way. For me personally, and it seems for many others, it could have saved a few gray hairs if the design of this feature gave a little bit more consideration to the user experience.
Not only is this issue a little bit annoying, but when you combine this with the fact that this contact will then get updated in CRM and subequently propagated to other users' contacts folder - well then you have data pollution. First of all, the change log is unnecessary and it doesn't take long before people start blaming "CRM" or the "Outlook Client" for making these unsolicited changes. Second of all, it can in fact make changes that you don't want. Like in the screenshot above where "USA" is being replaced by "United States" where you might have certain standards and/or functionality based on the specific values that appear in a particular field. Third of all, it generates unnecessary updates that need to be uploaded and then downloaded to all other clients ("what? I didn't make changes to those contacts..."). And let's not even mention the cryptic audit comment that is written to the notes that now will appear on all contact records that get updated and if the values get reverted back to what they were previously (i.e. the correct values) this audit will appear again and again...
This particular update seemed to occur only for internal company contact records and not for external contact records. And through various tricks of the trade I was able to verify 100% that this update was not coming from CRM - rather CRM was just the conduit for propagating it as described above. But the problem was that I could not attribute this to other 3rd party software... so it was a little hard convincing the client without another prime suspect.
I finally came across the following forum posting which seemed to describe the issue I was facing to a tee: http://social.technet.microsoft.com/Forums/en/outlook/thread/8fa240c6-fb3b-48fc-b7d4-8a82919e3912
In short, from this posting 2 prime suspects emerged. The most likely one being the "Microsoft Exchange global address list (GAL) synchronization with Microsoft Outlook 2010" feature and this feature can be disabled using Group Policy as described in this article: http://technet.microsoft.com/en-us/library/ff871432.aspx. This presumably resolves the problem globally as it uses Group Policy.
The second suspect is the "Social Connector" feature that is built into Outlook 2010 and which apparently also has this change logging feature. This can be disabled on a client by client basis by navigating as shown in the screenshot below.
As can be seen, the default is "update without prompting" - a little hard to understand why it would have been designed this way. For me personally, and it seems for many others, it could have saved a few gray hairs if the design of this feature gave a little bit more consideration to the user experience.
Tuesday, March 27, 2012
Views and Filters Toolkit
This codeplex project provides some very useful tools for manipulating views in MSCRM. Documentation of the various scenarios that this tool can handle is available in the code plex page and there is also ample documentation and use cases in the creator's blog.
For example, this can come in handy if you wish to push out and maintain a set of views to user groups. That is, similar to system views but rather than publishing organization-wide you can use this tool to push it out to a select group of users, department, business unit etc. Of course you could also achieve this by sharing a personal view with a list of users or teams - this therefore provides another option for achieving a similar objective. The main difference would be that although sharing would essentially share one view with multiple users such that if any of those users changed the view definition it would update the definition for everyone, whereas the tool would create an individual copy for each. There might be reasons for using both approaches although sharing would probably be the better approach most of the time.
One of the most useful features is the ability to centrally control the Outlook Filters. I say this with a bit of a caveat which will be explained at the end of this post (before going through the configuration steps you may want to review that caveat). By default Outlook Filters are configured individually on the user's desktop. So if you need to modify the default Outlook or Offline filter, you will need to modify the filter on each computer individually. This has long been a pet peeve of mine.
With this toolkit, you can define locally the Outlook download rule and deploy it globally (or targeted to users, teams etc.). The basic deployment scenario is as follows:
Once you have done so, you will now find the view that you defined copy to the "System Filters" tab in the user's Outlook Filters (and/or Offline Filters depending on your deployment scenario).
Works like a charm, doesn't it? Well almost... and here comes the aforementioned caveat. There is a fatal flaw based on my experience that I'm currently working with Microsoft support to fix.
The issue seems to be that while you can use the system view, the default "My Outlook Contacts" view is still required. To quote from Microsoft support:
Which for all intents and purposes negates the efficiences gained from using the System Filter approach - at least as far as I can tell. If anyone has a different perspective on this and has found that it does work in their environment I'd love to hear about it.
Update: This issue seems to be confirmed by this post and was resolved with UR5.
So what's the point of blogging about a feature that essentially doesn't work?
One last thing to mention is that it would also be nice to be able to globally deactivate the default "My Outlook Contacts" as even with a working solution there is still a manual step to go into the client and disable the rule so it doesn't interfere with the deployed system rule. Perhaps that can be done using the toolkit - I haven't looked into it. Will try to do so once this issue is (hopefully) resolved.
For example, this can come in handy if you wish to push out and maintain a set of views to user groups. That is, similar to system views but rather than publishing organization-wide you can use this tool to push it out to a select group of users, department, business unit etc. Of course you could also achieve this by sharing a personal view with a list of users or teams - this therefore provides another option for achieving a similar objective. The main difference would be that although sharing would essentially share one view with multiple users such that if any of those users changed the view definition it would update the definition for everyone, whereas the tool would create an individual copy for each. There might be reasons for using both approaches although sharing would probably be the better approach most of the time.
One of the most useful features is the ability to centrally control the Outlook Filters. I say this with a bit of a caveat which will be explained at the end of this post (before going through the configuration steps you may want to review that caveat). By default Outlook Filters are configured individually on the user's desktop. So if you need to modify the default Outlook or Offline filter, you will need to modify the filter on each computer individually. This has long been a pet peeve of mine.
With this toolkit, you can define locally the Outlook download rule and deploy it globally (or targeted to users, teams etc.). The basic deployment scenario is as follows:
- Define your personal view
- Create a workflow that looks something like the screenshot below (refer to the detailed instructions for specific settings, although the only information that you'll need to change to make this work will be the values for Personal and System View Name to match the names you have used)
- Manually run this workflow on the users to whom you wish to copy the view
Once you have done so, you will now find the view that you defined copy to the "System Filters" tab in the user's Outlook Filters (and/or Offline Filters depending on your deployment scenario).
Works like a charm, doesn't it? Well almost... and here comes the aforementioned caveat. There is a fatal flaw based on my experience that I'm currently working with Microsoft support to fix.
The issue seems to be that while you can use the system view, the default "My Outlook Contacts" view is still required. To quote from Microsoft support:
As I have found in other instances, when the My Outlook Contacts filter is disabled or deleted, it will cause contacts to lose their GUIDs and will also break the crmLinkState. Therefore, in order to guarantee that contact sync properly between CRM and Outlook, the My Outlook Contacts filter must be present and enabled.
Which for all intents and purposes negates the efficiences gained from using the System Filter approach - at least as far as I can tell. If anyone has a different perspective on this and has found that it does work in their environment I'd love to hear about it.
Update: This issue seems to be confirmed by this post and was resolved with UR5.
So what's the point of blogging about a feature that essentially doesn't work?
- It would appear based on the referenced post that this feature can be leveraged and this post serves to point out the issues encountered that might perhaps give a heads up to others who might be looking to configure this option and/or troubleshooting Outlook sync issues.
- I have to believe that this is something that will be plugged in the near future and I'm tracking it closely (and giving the support folks a little bit of a hard time) in order to facilitate resolution and therefore wanted to document while it's still relatively fresh in my head. And once fixed this post can serve as a reference to a working function.
One last thing to mention is that it would also be nice to be able to globally deactivate the default "My Outlook Contacts" as even with a working solution there is still a manual step to go into the client and disable the rule so it doesn't interfere with the deployed system rule. Perhaps that can be done using the toolkit - I haven't looked into it. Will try to do so once this issue is (hopefully) resolved.
Tuesday, March 13, 2012
Pending Update Contact Icon
After installing the CRM Outlook client you will have no doubt have noticed the CRM icon that gets associated to CRM contacts, emails, appointments etc. which is very useful to be able to determine visually that the record in question is in fact linked to CRM.
However you may have also noticed a contact icon that looks somewhat similar to the regular contact icon except that it has a little dot (clock?) in the bottom right hand corner. At first you may not even notice it but subconciously it will probably nag at you where you may feel that something seems amiss but you can't quite put your finger on it. Well that's kind of what happened to me....
... until I determined that in fact it was a distinct contact icon from the default contact icon. But then I was wondering whether it was CRM related or perhaps just something that I hadn't noticed before in Outlook. It certainly doesn't seem to have the appearance of being CRM related so initially I attributed it to something that I hadn't noticed before as part of Outlook behavior. But then the nagging question was - what did this similar-but-different icon denote? After all, there must be a reason for this variation...
In the end, it turns out that this in fact related to CRM. After you have made an update to a CRM contact and that update has not yet been synced to CRM, the contact will show with this icon. And once synced it will of course revert back to the standard CRM icon. So this icon indicates that limbo period between update and server sync. And I guess that little dot is indeed meant to be a clock...
Why this icon shows as a standard Outlook contact icon with a minor variation rather than the CRM Outlook icon with a minor variation (as it is very much still a CRM contact and it would be much clearer if it was depicted in this way) is a little beyond my understanding... But at least I now know what it means.
However you may have also noticed a contact icon that looks somewhat similar to the regular contact icon except that it has a little dot (clock?) in the bottom right hand corner. At first you may not even notice it but subconciously it will probably nag at you where you may feel that something seems amiss but you can't quite put your finger on it. Well that's kind of what happened to me....
... until I determined that in fact it was a distinct contact icon from the default contact icon. But then I was wondering whether it was CRM related or perhaps just something that I hadn't noticed before in Outlook. It certainly doesn't seem to have the appearance of being CRM related so initially I attributed it to something that I hadn't noticed before as part of Outlook behavior. But then the nagging question was - what did this similar-but-different icon denote? After all, there must be a reason for this variation...
In the end, it turns out that this in fact related to CRM. After you have made an update to a CRM contact and that update has not yet been synced to CRM, the contact will show with this icon. And once synced it will of course revert back to the standard CRM icon. So this icon indicates that limbo period between update and server sync. And I guess that little dot is indeed meant to be a clock...
Why this icon shows as a standard Outlook contact icon with a minor variation rather than the CRM Outlook icon with a minor variation (as it is very much still a CRM contact and it would be much clearer if it was depicted in this way) is a little beyond my understanding... But at least I now know what it means.
Wednesday, December 28, 2011
CRM 2011: The server address is not valid
I recently encountered another issue with being able to connect to the CRM server using the CRM Outlook Client. While specifying the connection information I was being presented with a "server address is not valid" message.
But this message was clearly off because the Server URL and organization were clearly correct.
To troubleshoot, I enabled the Troubleshooting using the CRM Outlook client Diagnostics tool (the way to go about this is described here). Reviewing the trace file I was able to identify the cause of the error i.e. the following text appeared indicating an authentication issue:
The resolution was simply to enable "Anonymous Authentication" to the CRM web site i.e.:
After performing the above steps, the client was able to connect to the CRM installation.
But this message was clearly off because the Server URL and organization were clearly correct.
To troubleshoot, I enabled the Troubleshooting using the CRM Outlook client Diagnostics tool (the way to go about this is described here). Reviewing the trace file I was able to identify the cause of the error i.e. the following text appeared indicating an authentication issue:
Error| Exception : The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'.
The resolution was simply to enable "Anonymous Authentication" to the CRM web site i.e.:
Monday, December 5, 2011
Microsoft CRM Email Resolution Issues
My previous post discussed promoting Outlook activities (email, appointments, activities) to CRM using Track and Set Regarding, the subtleties between these two options, and when it might be appropriate to use one vs. the other approach.
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:
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.
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
Friday, November 25, 2011
Microsoft CRM 2011 Track vs. Set Regarding
The question often arises in product demonstrations and when engaging with new clients as to the distinction between the "Track" vs. "Set Regarding" options for promoting emails to CRM (or any other type of activity for that matter i.e. appointments and tasks).
The short and obvious answer is of course that "Track" is a quick way to just promote the email into CRM without further classification (it can of course be classified later); whereas "Set Regarding" not only promotes the email to CRM but also classifies it to the appropriate account, contact, opportunity, case etc. at the same time.
As it is unlikely (in the real world that is) that an individual would later go and reclassify something that was promoted earlier, it is generally best practice to use the "Set Regarding" option to classify immediately so as to satisfy the "if-not-now, when?" dictum. And given that the CRM 2011 Outlook Client has now made it that much easier to use the "Set Regarding" option by maintaining a "recent" list of associated entities (see screenshot above) chances are that the time required to click Set Regarding vs. the single-click Track option is going to be anyway minimal, thereby reinforcing the aforementioned general best practice.
However what if I just want to promote and classify an email to the contact that sent me the email? It seems kind of silly to have classify the email to the contact that sent me the email by using "Set Regarding" since the email already is implicitly classified by the "From" email address that it was sent from (or "To", "Cc", "Bcc"). Shouldn't it auto-classify and not require me to reclassify again by using the "Set Regarding"? That would just seem like common sense, wouldn't it?
And fortunately the answer is that this is not only common sense but also how CRM will actually handle it. To understand, let's first analyze how CRM handles the email distribution list. It is important to note that the handling of the email distribution list is the same regardless of whether you use the "Track" or "Set Regarding" option so the next paragraph applies to both techniques.
In a nutshell, CRM will try and auto-resolve all the contacts on the email distribution list to a CRM contact, or user record. This is best illustrated by viewing it in the Microsoft Dynamics CRM panel below the email and also in the CRM email record itself after having click "View in CRM"
If CRM is able to successfully resolve the email to a contact record, the email will then appear in all the resolved contacts "Closed Activities".
Not only that, the email will also appear in parent "related regarding" roll-up views.
To re-iterate, all the above is performed as part of email resolution process regardless of whether you elected to use "Track" or "Set Regarding". Which therefore means that had you just used the "Track" option for the email, you still are able to have it be associated with the appropriate contact and parent account.
Therefore for emails (appointments and tasks) if your only requirement is to track the email to the corresponding contact record in CRM then selecting "Track" should be sufficient (assuming the contact exists - there are also options for auto-creating the contact if not, but that again is a topic for another discussion). In this scenario, using the "Set Regarding" is arguably redundant. However if you wanted to related the email to some other "less obvious" entity (case, opportunity, etc.), then you obviously would need to make use of the "Set Regarding" feature as per the aforementioned best practice.
The short and obvious answer is of course that "Track" is a quick way to just promote the email into CRM without further classification (it can of course be classified later); whereas "Set Regarding" not only promotes the email to CRM but also classifies it to the appropriate account, contact, opportunity, case etc. at the same time.
As it is unlikely (in the real world that is) that an individual would later go and reclassify something that was promoted earlier, it is generally best practice to use the "Set Regarding" option to classify immediately so as to satisfy the "if-not-now, when?" dictum. And given that the CRM 2011 Outlook Client has now made it that much easier to use the "Set Regarding" option by maintaining a "recent" list of associated entities (see screenshot above) chances are that the time required to click Set Regarding vs. the single-click Track option is going to be anyway minimal, thereby reinforcing the aforementioned general best practice.
However what if I just want to promote and classify an email to the contact that sent me the email? It seems kind of silly to have classify the email to the contact that sent me the email by using "Set Regarding" since the email already is implicitly classified by the "From" email address that it was sent from (or "To", "Cc", "Bcc"). Shouldn't it auto-classify and not require me to reclassify again by using the "Set Regarding"? That would just seem like common sense, wouldn't it?
And fortunately the answer is that this is not only common sense but also how CRM will actually handle it. To understand, let's first analyze how CRM handles the email distribution list. It is important to note that the handling of the email distribution list is the same regardless of whether you use the "Track" or "Set Regarding" option so the next paragraph applies to both techniques.
In a nutshell, CRM will try and auto-resolve all the contacts on the email distribution list to a CRM contact, or user record. This is best illustrated by viewing it in the Microsoft Dynamics CRM panel below the email and also in the CRM email record itself after having click "View in CRM"
Microsoft Dynamics CRM Panel
View in CRM
If CRM, cannot resolve a contact from the distribution list, it will show as unresolved - but that is a topic for another time.
If CRM is able to successfully resolve the email to a contact record, the email will then appear in all the resolved contacts "Closed Activities".
Not only that, the email will also appear in parent "related regarding" roll-up views.
To re-iterate, all the above is performed as part of email resolution process regardless of whether you elected to use "Track" or "Set Regarding". Which therefore means that had you just used the "Track" option for the email, you still are able to have it be associated with the appropriate contact and parent account.
Therefore for emails (appointments and tasks) if your only requirement is to track the email to the corresponding contact record in CRM then selecting "Track" should be sufficient (assuming the contact exists - there are also options for auto-creating the contact if not, but that again is a topic for another discussion). In this scenario, using the "Set Regarding" is arguably redundant. However if you wanted to related the email to some other "less obvious" entity (case, opportunity, etc.), then you obviously would need to make use of the "Set Regarding" feature as per the aforementioned best practice.
Friday, November 11, 2011
Lync Presence in CRM Outlook Client
My previous post highlighted some of the enhancements that Update Rollup 5 has brought to the table.
The last one on that list - CRM Outlook Client enhancements - includes fixing a pet peeve that was noticeably absent until now. Which was the lack of an integrated Lync presence on the CRM Outlook Client. This seemed to be a glaring oversight as it did work in CRM 4.0. We had logged this as a support ticket to Microsoft and the response we received was none too encouraging and I quote:
Anyway, this story of course has a happy ending. The support rep indicated that the enhancements would be possible in a future release of CRM. When he said that I assumed that it would be pushed out, at a minimum, to the next major release of CRM. But I guess it depends on how you define "release" and in this case it seems to be that Update Rollup is classified as a release. Either that or Microsoft development changed their mind but either way I'm not complaining.
Below is a screenshot illustrating the user experience (I couldn't get anyone else to pose so you'll have to settle for an image of moi).
The last one on that list - CRM Outlook Client enhancements - includes fixing a pet peeve that was noticeably absent until now. Which was the lack of an integrated Lync presence on the CRM Outlook Client. This seemed to be a glaring oversight as it did work in CRM 4.0. We had logged this as a support ticket to Microsoft and the response we received was none too encouraging and I quote:
Thank you for your patience, I wanted to give an update on this. Our Escalation Engineers have determined that this is functioning by design and will not get fixed in the current release of CRM. This functionality worked within CRM 4.0 client because CRM data was display on web pages which allowed presence data to be displayed. In CRM 2011, our development team opted to give CRM more of an integrated look and feel with Office, so standard Outlook controls were used. As a result, the control in which CRM uses to display data does not support the usage of presence data.
To implement functionality to include presence data within Outlook would require a redesign of how the CRM client displays data. Such a redesign will not come in the middle of a product lifecycle but it certainly is possible for a future release of CRM. Please feel free to submit this as a product suggestion to our developers at https://connect.microsoft.com/dynamicssuggestions/
Let me know if you have any remaining questions on this issue. If you do not, I will go ahead and archive this support incident.
Anyway, this story of course has a happy ending. The support rep indicated that the enhancements would be possible in a future release of CRM. When he said that I assumed that it would be pushed out, at a minimum, to the next major release of CRM. But I guess it depends on how you define "release" and in this case it seems to be that Update Rollup is classified as a release. Either that or Microsoft development changed their mind but either way I'm not complaining.
Below is a screenshot illustrating the user experience (I couldn't get anyone else to pose so you'll have to settle for an image of moi).
Wednesday, November 9, 2011
Where did my Outlook reminders go?
If like me you've suddenly noticed that Outlook reminders for tasks, appointments etc. are no longer appearing (hopefully not as a result of having missed an important meeting or such like), then you may want to read on.
This issue occurs for Outlook 2010 and it appears to have not been fixed in the Outlook Rollups. But you may want to install the latest rollup (UR5 as of this writing) before going any further.
The cause of the issue is highlighted in KB article 2584053.
You can download the hotfix from here. It goes without saying that you should select the correct version (if using IE it should auto detect that for you), and then follow the instructions to have the fix emailed to you.
After installing, create a test reminder that is in the past to ensure that it comes up as soon as you have entered it to ensure that this has indeed fixed your issue.
Monday, November 7, 2011
There is a problem communicating with the Microsoft Dynamics CRM Server
We received this error while trying to configure the CRM Outlook Client for CRM 2011:
This was from a machine where we were able to connect to CRM 2011 using Internet Explorer so it was a little perplexing why we should be receiving a communication error as indicated in the error message issued above.
In order to resolve, the following steps were taken:
This was from a machine where we were able to connect to CRM 2011 using Internet Explorer so it was a little perplexing why we should be receiving a communication error as indicated in the error message issued above.
In order to resolve, the following steps were taken:
- Enabled Tracing by going to Start | Microsoft Dynamics CRM | Troubleshooting tab and enabled tracing
- After reproducing the error retrieve the trace files from %Userprofile% \Local Settings\Application Data\Microsoft\MSCRM\Traces
- Analyzed the trace file to find the source of the error
It turns out that in our case there was an errant plugin that was causing the error as indicated in the logs:
In this case, we had upgraded from CRM 4.0 and although the plugin above still worked (using IE navigation), it apparently was troubling the CRM Outlook Client for reasons that are not entirely understood. Anyway, disabling/removing the plugin resolved the CRM connection error that we were experiencing.
In conclusion, it turns out of course that the error message itself was a little misleading because as we discovered - the issue was related to a wayward plugin rather than connectivity.
Monday, July 18, 2011
Outlook CRM contact not showing with a CRM icon
We encountered the scenario where a contact that was clearly marked as a synced CRM contact was not showing in the Outlook client with the CRM icon,
We discovered the reason for this. In this case the client wanted centralized contact management. Meaning they did not want the ability for any of the end users to be able to update the contact record other than through a central admin user to protect the integrity of the contact data. They were not satisfied with data audit or alternative workflow/notification options.
And in addition they also wanted the ability to have the contacts be synced with the end users' Outlook clients. Since there is nothing preventing a contact from being updated in Outlook via the end users, we had to prevent any contact updates from hitting the CRM server during the syncing process by removing the contact update privileges from these end users.
And therein lay the problem with the contact icon. The following is a scenario where a CRM contact in Outlook can have it's contact icon flip back and forth between the standard Outlook contact icon and the CRM contact icon:
We discovered the reason for this. In this case the client wanted centralized contact management. Meaning they did not want the ability for any of the end users to be able to update the contact record other than through a central admin user to protect the integrity of the contact data. They were not satisfied with data audit or alternative workflow/notification options.
And in addition they also wanted the ability to have the contacts be synced with the end users' Outlook clients. Since there is nothing preventing a contact from being updated in Outlook via the end users, we had to prevent any contact updates from hitting the CRM server during the syncing process by removing the contact update privileges from these end users.
And therein lay the problem with the contact icon. The following is a scenario where a CRM contact in Outlook can have it's contact icon flip back and forth between the standard Outlook contact icon and the CRM contact icon:
- The Outlook client user actually updated one of the CRM contacts in Outlook.
- During syncing the user would first get a permission error (that can be ignored) and then the icon would change to a standard Outlook contact icon (as the sync process would presumably think that since the contact can no longer be updated that the contact is no longer a CRM contact).
- The icon will remain a standard Outlook icon until a change is made again to the contact on the Web client at which time the change would be synchronized to the Outlook client and the contact icon would update again. Note that a duplicate contact would not be created since even though the contact was no longer showing as a CRM contact in Outlook, the CRM contact GUID wherein the actual link to the CRM server contact is housed, would remain intact and hence the sync process could still locate the contact record in the client.
Why the CRM contact icon is therefore not determined by the presence or absence of the CRM contact GUID is beyond me... Sigh. Anyway, this is presently a program "feature" in CRM 4.0. I have not tested this function in CRM 2011 yet.
Subscribe to:
Posts (Atom)