Have you ever read about a new feature, or noticed in the latest Update Rollup (UR) a feature, or even a fix, that didn’t really made a lot of sense to you!? Working with enterprise customers I actually get to see the logic behind some of these, however still not all of them.
Every time I’ve 3 features to talk about I’ll blog about it, check first blog here, this time I’m talking about:
Change default behavior of the lookup of “Set Regarding" button, defaults to Account entity –UR11
Tracking emails for contacts that have duplicate emails not tracked properly – UR8
Long running queries (more than 250ms), related to counting the total amount of records in a grid view –UR6
1- Change default behavior of the lookup of “Set Regarding" button from Accounts – UR 11
When using “Set Regarding” button, if you click the lookup button and then the "More" button, by default it lists accounts in the entity field. This might not be convenient if end users are never going to choose it and always go for another entity.
This behavior could be frustrating and very expensive in terms of time los, if you have thousands or even hundreds of end users doing these transactions on daily basis. This is very likely if they are using a custom entity, or even a standard entity with a drop down list that has 20 entities or more.
The above setting will accept the value of the new entity (Logical name) that end users would like to default to. Remember to use a supported method to change the setting, such as using the OrgDBOrgSettings Tool. For example, the below statement sets the default Set Regarding lookup entity to Opportunity entity:
Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Update /u testOrg SetRegardingLookupDefaultEntityType opportunity
2- Tracking emails for contacts that have duplicate emails not tracked properly – UR 8
When multiple records with the same e-mail address exist in the Dynamics CRM Organization, and e-mail is auto tracked, the e-mail is resolved to the record that was created first.
In some business scenarios you may have different representatives (call them S1 and S2) with one of their contacts (call them C1 and C2) having same email address. Such as a generic alias where their team receives communications. Now when either C1 or C2 sends an email that email is getting tracked in CRM for the contact record that was created first in CRM. So, if C1 was created first, the incoming email from this common email address will always get tracked against C1 irrespective of whether the email was sent in reply to an email from S1 or S2.
Using the above setting OverrideV5SenderConflictResolution, this setting will allows you to override that functionality as follows:
- False – E-mails are tracked to the first record created-Default.
- True – E-mails are not tracked automatically if there are multiple records with the same e-mail address..
Remember if you are going to use this setting, use supported methods to do that. (Ex: OrgDBOrgSettings Tool), for example the below statement set the setting value to True:
Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Update /u testOrg OverrideV5SenderConflictResolution True
3- Controlling "Page count" functionality, related to counting the total amount of records in a grid view – UR 6 and UR 10
Controlling the "page count" functionality that returns the total amount of records in a grid view.
It’s a new feature in CRM 2011 that tells you how many (total) records that view has retrieved for you, so you don’t have to scroll to the last page and find out the count manually. However in some scenarios that functionality might not have business need or not required by end user. You can enable / disable this functionality with the above setting. Before UR 10, disabling this setting could provide performance gain, but in UR 10 that was fixed, so no need to disable it to gain performance if you have UR 10 or later installed.
To control this functionality, use the settings SkipGettingRecordCountForPaging to disable the record count query. When the setting is set to true, the "select COUNT(*) as [#TotalRecordCount]" query is skipped and the total record count is not returned in a view. This query is responsible for getting the total number of records returned for each view. This query can cause longer search times and may lead to SQL timeouts.
- False – Enables record count on views.
- True – Disables record count on views. This option is off by default. (Value: 0)
Remember if you are going to use the setting, use supported method to do that. (Ex: OrgDBOrgSettings Tool) ), for example the below statement sets the value to True:
Microsoft.Crm.SE.OrgDBOrgSettingsTool.exe Update /u testOrg SkipGettingRecordCountForPaging True
That’s it for this episode, Thank you