Tuesday, September 27, 2016

Lead Qualify as opportunity and duplicate detection

In the sales process normally, you would create a lead and then promote that lead to an opportunity by clicking on the qualify button. When this happens, the CRM creates an opportunity and a contact record.

If there are duplicate detection rules created for the contact record, when you try to qualify a lead it would first bring a small dialog box stating that there could be potential duplicates (Displays both account and contact lookups) and to select one from the list.

One thing is that this appears even if there are no duplicate records as well. If you unpublish the duplicate rules for contact, then this dialog box doesn’t come up. If the rules might be needed we cannot unpublish them.

Some clients don’t like this at all as it doesn’t give a user friendly box with potential duplicates are being marked. Also even though there are no duplicates this might pop up.
Luckily we can turn this off by writing a plugin.

The plugin has to be using the “Lead Qualify” message and have to write for the pre validation stage of lead.

In the C# code you need to write the below twice.

localContext.PluginExecutionContext.InputParameters[“SurpressDuplicateDetection”] = true;
localContext.PluginExecutionContext.InputParameters[“SurpressDuplicateDetection”] = true;

This would prevent from displaying the dialog box completely.


If you want to show the dialog box, if there are duplicates then you can write code to check for duplicates based on the criteria you have been given. Then only if there is a duplicate, you can display the dialog by putting the below 2 statements in an if else condition.

Duplicate Detection Rules

In CRM, we do have an OOTB functionality which lets you check for duplicates. This would however, would not stop one from saving the record but letting know the operator that there is a duplicate. This is in a way good as it, lets the operator decide whether to use the existing record or to continue with using a new record.

There are some good features of this as well as there are some limitations.
Main limitations are
  • You can have only 5 published duplicate detection rules per entity
  • The combination of the match code cannot exceed 450.
These probably have been given to stop one from having performance issues.
If you want a new rule and the entity has exceeded the rule limitation, then you would have to unpublish one rule and get this created. For on premise CRM instances you can change this, but it is unsupported. For Online instances, the unsupported cannot be done.

For Match code though you have alternatives. However, this might not always work, but would be good to know them as well.

For an instance when you create a record for contact and if you want to check for duplicates using first name, last name and street 1, the match code length becomes 352. Now it would be difficult for you to add couple more fields as you only have spare 98 length left from 450.

Most of the time street1 length would not exceed for a live record more than 50(Depends on the requirement). If this is the case then what we can do is instead of having the criteria as “Exact Match”, we can have the filter as “Same First Characters” and give a character length of 50. By doing this we can reduce the match code from 352 to 152, which allows us to add more fields if required.

Apart from that, you do have the operator “Same Last Characters” and can give the character length too.

Also one good thing about this is you can check against another different entity as well. If you need to check when creating a lead record, whether there are contact records with a matching criteria this is also possible.
Apart from that you can check for the following as well.

  • Case sensitiveness of characters
  • Include/Exclude inactive records
  • Ignore blank records

Retrieving Calendar of a Bookable Resource in Dynamics

There are occasions where we need to retrieve working days and working times of a resource in Dynamics grammatically. This is quite possible...