Mitch Milam's Dynamics CRM and xRM Discussions

Recently, we ran into an issue with some custom JavaScript code that we had added to an Opportunity form.

The issue didn’t surface until with enabled duplicate checking on the Opportunity and it took a call in to Microsoft and about three days of work to track down the issue, it’s cause, and find a work around.

That’s what you sometimes get when you add unsupported code to your solution. :)

Anyway, I learned a lot about how the CRM 4.0 Duplicate Checking feature actually works and thought I’d share it with you today.

The Duplicate Checking Process

Believe it or not, much of the duplicate checking process doesn’t actually happen when you Save a record, it actually happens when you Load the record.  That is what cause me so much pain and anguish because.  I was looking at the OnSave event not the OnLoad event.

Here’s how it works behind the scenes:

1) You click one of the Save buttons on the form.

2) If duplicate checking us turned on, and you do have a duplicate, the following exception will be generated:

Crm Exception:

Message: A record was not created or updated because a duplicate of the current record already exists.

ErrorCode: –2147220685

3) When the CRM Form is reloaded, it checks to see if the save operation generated an error with an ErrorCode of:  0×80040333.  This is the hexadecimal version of –2147220685.

4) If that ErrorCode was indeed generated, it knows that a duplicate was detected.  Some extra JavaScript is injected into the CRM Form page load and the duplicate checking dialog is displayed.

Note: During this process, CRM will scan the CRM Form and send any field containing data to the duplicate checking dialog. ( or so it appears )

5) When the Duplicate dialog is displayed, you have two options: Save Record, Cancel.

5a) Clicking Save will save the record and reload the form.

5b) Clicking Cancel will simply dismiss the Duplicates dialog.

What Got Us into Trouble

As I mentioned earlier, we were doing some unsupported customizations on the form to provide the users with a specific experience.  This involved adding a custom control to the form via JavaScript.

We got into trouble in Step 4, above, because CRM was:

1. Collecting that form field
2. Looking in the database for that field
3. Not finding it
4. Throwing an exception

Unfortunately, the exception was never shown on the screen.  All you saw was the spinning progress indicator on a blank Duplicate Detection dialog – that never went away.

We simply modified the time and place where we were creating the custom field and since it was moved out of the OnLoad event, it didn’t interfere with the Duplicate Checking.  And, since the CRM Form reloads after a save operation, the custom control was not present during the Duplicate Checking operation and caused no further issues.