Salesforce merge accounts from one reviewed list of duplicate accounts

Accounts arrive from everywhere. A rep creates "Summit Ridge Health" from a call, a list import brings in "Summit Ridge Health LLC", a web form or marketing sync creates a third, and an acquisition adds a whole second book of customers with its own spellings. Duplicate rules only fire when a record is created or edited through a path that respects them, so years of imports and integrations leave a backlog nobody planned for.

The cost lands on the people who use the accounts. Two reps work the same company without knowing it, opportunities and cases split across records, renewals get forecast twice, and the account count in a board report is higher than the number of real customers. By the time someone asks for a cleanup, the backlog runs to hundreds of groups.

Three. Salesforce Help says to select up to three accounts to merge, and the API merge call has the same ceiling: one master and at most two others per call. A company with five account records therefore takes two merges, and a backlog of 400 groups takes at least 400 merge actions. That is why the decision about which records belong together has to be made before anyone opens the merge screen.

Mass merge apps on the AppExchange batch these calls for you, but they still need a rule that says which accounts are the same company. Any rule good enough to run unattended is one you want to have read on a sample first.

Salesforce Help lists the Delete permission on accounts as a requirement, and the user has to be a Salesforce admin, the account owner, or above the account owner in the role hierarchy. Merging person accounts needs the same access on person accounts, and person accounts are available in Enterprise, Performance, Unlimited and Developer editions.

In practice that means a sales ops admin does the merges while reps own the accounts. A merge list the reps have seen beforehand, with each group and its reason, turns "who deleted my account" into a review that already happened.

No. Salesforce merges business accounts with business accounts and person accounts with person accounts, never one with the other. If a consumer bought as an individual and later through a company, those stay two records and you link them with a relationship instead. Split the export by record type before matching, so the pass never proposes a pair Salesforce will refuse.

Not really. The accounts that lost the merge go to the Recycle Bin, and you can restore them while they are there. Restoring brings back the deleted records, but the field values and related records already moved onto the master stay on the master, so you are left reassigning contacts and opportunities by hand. Treat every account merge as permanent.

Salesforce keeps the Created Date and Created By of the oldest record in the merge on the surviving account, and the merge shows as its last modification. The audit log from the pass fills the rest of the gap: which Account IDs were merged into which, and the reason given at the time.

They follow the master. Contacts, opportunities, cases, activities, notes and attachments on the losing accounts are reparented to the account you keep, and account team members from every record are kept on the master. Nothing on those child records is deleted, which is good, and also means a wrong merge drags a stranger company history into the account.

Ownership is the part that causes arguments. The master keeps one owner, so a merge can quietly move a customer out of a rep book and with it the open opportunities that drive commission. The pass shows Account Owner as a conflict on every group where the owners differ, so sales leadership can settle ownership before the merge, not after a quota dispute.

Build an Accounts report in tabular format with Account ID, Account Name, Website, Billing Street, Billing City, Billing State, Billing Zip, Phone, a billing or main email field if your org has one, Account Owner and Record Type. Filter to the record types you plan to merge, then export it as a CSV. Data Loader or the weekly data export work just as well and return the 18 character Account ID, which is the safe one to join on.

Keep the headers plain, as Salesforce names them. Then load the file into the demo at the top of this page. Nothing uploads, the accounts are read and matched inside your browser tab, and the audit log keeps the Account ID next to every decision so your admin can find each record again.

Every duplicate account copies across when the org feeds another system. An ERP or billing integration creates one customer per account, a marketing platform syncs both, and a migration to another CRM loads both as companies. Cleaning the accounts first is cheaper than cleaning them in two places afterwards. The import side of a move into Salesforce is covered in HubSpot to Salesforce migration, and leads and contacts in the same org are covered on Salesforce deduplication.

Contacts merge under the same three record rule, with two differences worth planning for: a lead cannot join a contact through the merge screen, only through conversion, and every contact carries an owner of its own. Both are set out on Salesforce merge contacts.

The buyer is the sales ops or RevOps admin with a backlog of duplicate accounts, an acquisition to fold in or an integration about to go live, and a sales team that will notice every account that changes hands. They need the merge list decided before the merges, and a record of why each group was merged when a rep or the CFO asks.

DataUntangler is a data cleaning tool on the Analyst plan at 59 dollars a month, or 348 dollars a year, with unlimited files up to about 100,000 rows each. It does not connect to your org and writes nothing to it. You export, review the groups, and run the merges in Salesforce yourself, in batches of three.