Lead conversion depends on more than just the name. It also depends on the sharing model, the user's permissions, and the configuration of Duplicate Management. See Convert Qualified Leads for the permissions you need to give your users.
Generally speaking, if the system won't let you select an account or contact, it's because there were no matching records, as determined by account name and last name (not email, phone, or address, just name fields) that the user can edit.
There's some leeway in what the system allows for name matches. For example, if the company name is Acme, and the account name is Acme, Inc, then Salesforce presents an option to convert into the existing account. Likewise, if the contact is Robert Smith, and the lead is Bob Smith, and they have the same account, Bob Smith can be converted to Robert Smith.
Generally speaking, if duplicates are a concern, consider enabling Duplicate Management. It will actually warn the user if they're about to create a duplicate, based on standard or custom matching rules to suit your organization's purposes.
If, after checking all your settings, you still feel like it's a system glitch, consider contacting support with some concrete examples. I've never seen the system not offer the correct records to convert to as an administrator, and for my users, I've always been able to trace it down to a sharing problem or a typo.
While there is no way to bulky the code (as described in this answer), it is possible to create a process that will do the same as schedulable batchable job, instead of an insert/update trigger.
Steps:
- Implement a system field that will carry ID of a master record.
- Create an APEX class or a flow that will update duplicate record with master record id.
- Create schedulable batchable APEX class that will address marked records in small batches.
Pros of this method: free
Cons: you or your developer must maintain merge rules in APEX. The merge is not instant.
Alternatives:
A. Use an application from AppExchange. There are quite a few available for any budget.
B. Use a custom object to store pairs of ids (master, dupe). This will allow you to reduce amount of code that run by onUpdate trigger. (Make sense only if you have a dozens of them).
In my Org I am currently using a combination both solutions. The simple scenarios are identified and managed by Triggers/scheduled batches and the complex scenarios (when lots of business logic should be applied before merge) are handled by de-duplication application.
Best Answer
I would only expect the merged Contacts to have AccountContactRelations if the source Contacts had them. Is that the case? The merge operation doesn't do any work to maintain the semantics of your data; it just combines field values and reparents existing child records. I would not expect it to create new relationships.
This is something that could be implemented in an after delete trigger on Contact. Iterate through the Contacts in
Trigger.oldMapand check for a value in theMasterRecordIdfield. If that field is populated, the contact is the losing record in a merge. You could then construct and insert anAccountContactRelationbetween the winning Contact (whose id is theMasterRecordId) and the losing Contact's Account.