Matched Contact causes accountId must be specified if contactId is not null error

[kyleschmid]

When a lead convert gets a duplicate error from a duplicate contact, the MatchRecord doesn't always return the AccountId as one of the fields on Contact. This causes the setAccountId() method to set a null AccountId. When the lead tries to convert, an "accountId must be specified if contactId is not null" error is thrown.

[karamcintyre]

I am concerned this may be a configuration issue and not a code issue. Would you be able to send a screenshot or information from the org where you are seeing this so we can look into this? This is what we would need to see:

• Screenshot of the list of Matching Rules that are active, or a list of the matching rules and objects for those rules that are active
• Screenshot of the list of Duplicate Rules that are active, or a list of the duplicate rules and how they are built that are active
• Screenshots of the criteria for each Matching Rule that is active
• Screenshot of the standard mappings for Lead to Contact (this can be found in Setup in the Lead object by clicking on the mapping button on the list of fields.

[kyleschmid]

@karamcintyre It was just the standard Lead, Contact, and Account matching/duplicate rules that were all set to Alert on create. The Lead/Contact mappings were all standard as well.

After some extensive debugging, I found that the Contact object returned by the MatchRecord object (here) didn't include all Contact fields as part of the instance of the object (no different than if you leave out a field when during a query). The AccountId was one of the fields that wasn't being returned. I believe it may have been because the Account wasn't one of the things that triggered the duplicate exception, but I'm not sure. The Contact object returned looked something like:

Contact: {Id = 003000000000000AAA, FirstName = 'Kyle', LastName = 'Schmid', Email = '[email protected]'}

So when the processor was calling setAccountId() (here), null was being returned.

[karamcintyre]

When you say "standard" you mean the standard Salesforce matching rules that cannot be edited that come with an org, correct? Those cannot be activated when Interactions is installed because they are not formatted in the correct way to allow the code to use the information when it encounters a duplicate, specifically Account. Even though they are set to Alert, they will still error and the code will attempt to use that information but it won't be able to.

You need to create custom Lead and Contact Matching Rules and activate those, and they must follow the formatting specified on pages 39-44 of the Configuration and Installation Guide. If you follow those steps to the letter and deactivate any matching rules that do not follow the correct format, I'm confident you will not see this anymore.

I'm going to have a developer look at the pull request for this, but I don't think what you're seeing is because of an issue with the code, so I'm concerned the proposed changes could disrupt functionality.

[kyleschmid]

@karamcintyre I think the part of the format with "Company" is what triggers the Account to be returned, which makes sense. There may be some issues between orgs with the HEDA Last Name + Administrative Account format for existing Contacts vs. the Last Name, First Name format. The code changes in the pull request only run if the Account ID isn't found to begin with and essentially just query for the matched Contact's Account ID, so you may want to think about including it as a fail-safe.

[karamcintyre]

We're taking a look. I'll reopen it for the time being, if you could test the corrected matching rules to confirm that the issue you ran into is solved, that would help us a lot.

[kyleschmid]

@karamcintyre I'm unable to reproduce the issue in a couple of different orgs I tried using the same setup that the issue was occurring in (don't want to revert changes in that org because it's production). The standard duplicate rules are being used (not the format from the instructions), but debug statements are showing the Account ID being returned as part of the matched Contact. I'm not sure what the perfect storm of configuration is that led to this issue, but it was definitely there.

[karamcintyre]

@kyleschmid Have you tested all the different use cases around matching records with Interactions using the orgs that use default rules instead of Interaction rules? I find it really surprising that Interactions could function when the duplicate rules are not setup according to the documentation.

[kyleschmid]

@karamcintyre No, I didn't test all the different use cases/matching criteria. I was focused on the First/Last Name and Email matching. That worked without issue with the default rules in the development sandbox I tested in but was giving me the issue in a client's production org.