Quick Answer
Salesforce merging requires Delete permission because of what a merge actually does under the hood: the non-surviving records are deleted, and their child records are reparented to the winning record. There is no standalone "Merge" permission — Delete on the object is the gate. That design forces an uncomfortable admin question: how do you let users clean up duplicates without handing them the ability to delete records outright? The practical answer is to grant Delete narrowly (a permission set for a small data-steward group), hide Delete buttons on layouts and Lightning pages as a UI speed bump, require duplicate review before merging, and keep a recovery path through the Recycle Bin. Vantage Point's Salesforce consultants set up this exact pattern during org security reviews.
TL;DR
- Merging requires Delete permission on the object because the losing records are deleted and their related records move to the survivor.
- There is no separate "Merge" permission in Salesforce — object-level Delete is the control.
- Hiding the Delete button is a UI convenience, not a security control; the permission still works through the API and list views.
- The safe pattern: grant Delete via a permission set to a small group, remove it from base profiles, and route duplicates through a review queue.
- Merged-away records land in the Recycle Bin, so you have a recovery window — but don't treat it as an audit trail.
What Actually Happens When You Merge Two Records?
A Salesforce merge is not a soft link or a flag — it is a destructive operation with a survivor. When a user merges two accounts (or contacts, or leads), they pick a master record, choose which field values win on a field-by-field basis, and confirm. Salesforce then does three things:
- Deletes the losing records. The non-master records are removed and moved to the Recycle Bin, where they sit until the bin's retention window expires or someone empties it.
- Reparents the children. Related records — opportunities, contacts, cases, activities, notes, attachments — are moved from the losing records to the master. This is the valuable part of a merge, and the reason a merge beats a manual delete-and-rekey.
- Discards what you didn't pick. Field values on the losing record that you didn't select in the merge screen are gone with the record (recoverable only from the Recycle Bin while it lasts).
Because step one is a deletion, Salesforce requires the same permission it would require if the user clicked Delete on each losing record by hand. From the platform's perspective, that's exactly what the user is doing.
Is There a Separate "Merge" Permission?
No. This surprises a lot of admins, and it's the root of most merge-permission confusion. Object permissions in profiles and permission sets include Read, Create, Edit, and Delete — plus the "View All" and "Modify All" superpowers — but there is no Merge checkbox. Merge is treated as a composite operation: edit the survivor, delete the losers, reparent the children. The highest required permission in that composite is Delete, so Delete is what gates the whole action.
Two consequences follow. First, you cannot technically enable merging while blocking deletes — anyone who can merge can also delete records one at a time, through the UI, through list views, or through the API. Second, any merge strategy is really a Delete-permission strategy: who gets it, on which objects, and what guardrails surround it.
What Permissions and Sharing Access Does Merging Require?
Object permission is only half the story — record-level sharing still applies. A user needs both the object-level permission and sufficient access to the specific records involved.
| Object | Object permissions | Record access needed | Notes |
|---|---|---|---|
| Accounts (business or person) | Read, Edit, Delete on Accounts | Edit access to all records being merged | Related contacts and opportunities reparent automatically; portal-enabled contacts can block a merge until handled |
| Contacts | Read, Edit, Delete on Contacts | Edit access to the contacts and visibility of the parent account | Contact roles, campaign membership, and case associations move to the survivor |
| Leads | Read, Edit, Delete on Leads | Edit access to the leads | Merging into a contact during conversion follows lead conversion rules instead |
In private sharing models, the sharing requirement trips people up more often than the object permission: a rep can hold Delete on Contacts and still fail a merge because they can't edit one of the two records. If merges fail intermittently for some users, check sharing before permissions.
How Do You Grant Merge Access Without Opening the Delete Floodgates?
Since you can't separate merge from delete, the answer is layered controls around a deliberately small permission footprint. The pattern that works in most orgs:
1. Remove Delete from base profiles
Most users should never delete accounts, contacts, or leads one-off. Take Delete off the profiles entirely, so the default state is "no deletes, no merges."
2. Create a "Duplicate Management" permission set
Grant Delete on the mergeable objects in a single permission set (or permission set group), and assign it only to trained data stewards or a duplicate-review team. Permission sets are auditable and easy to revoke — far better than cloning a profile for three people.
3. Hide Delete buttons as a speed bump
Remove the Delete button from page layouts and Lightning record pages, and suppress it in list-view actions where practical. Understand what this does and doesn't do: it prevents careless clicks, but it is not a security boundary. A user with the permission can still delete through the API, data loader, or browser dev tools. Treat button-hiding as accident prevention, not access control.
4. Put a process in front of the merge
Pair the permission with Salesforce's duplicate rules and matching rules so duplicates surface through reports and dashboards rather than ad-hoc discovery. Many teams run a weekly review: duplicates are flagged, a steward confirms the survivor and field choices, then merges. That review step is your real safety net.
5. Know your recovery path
Merged-away records go to the Recycle Bin, where they can be restored during the retention window — restoring brings back the record and its relationships. But the Recycle Bin is a recovery tool, not an audit log: it isn't queryable in a report-friendly way, and items age out. If your compliance posture requires a merge audit trail, evaluate AppExchange duplicate-management tools that log every merge with before-and-after values.
What Are the Most Common Mistakes?
- Granting Modify All to fix a merge error. Modify All Data solves the sharing problem by ignoring sharing entirely — and hands the user delete access to every record in the org. Fix the sharing gap instead.
- Believing a hidden button equals no delete. It equals fewer accidental deletes. Determined or scripted deletes still work.
- Forgetting integrations. If a merging-away record is the sync anchor in an integration (the ID another system stores), the integration breaks silently. Check external ID mappings before bulk merges.
- Merging in production without a test run. Rehearse merge behavior in a sandbox with realistic data, especially when portal users, person accounts, or managed packages are involved.
- No owner for duplicates. If everyone is responsible for data quality, no one is. Assign the permission set — and the review queue — to named people.
What Should Businesses Do Next?
Start with an inventory: which profiles and permission sets currently grant Delete on accounts, contacts, and leads, and to how many users? Most orgs discover the answer is "more people than we thought." Then decide who your data stewards are, move Delete into a single permission set assigned only to them, hide the buttons for everyone else, and stand up a duplicate-review routine. Rehearse the whole flow in a sandbox before touching production. If your org runs duplicate rules but nobody acts on them, fixing the permission model is what finally makes the rules useful.
How Vantage Point Helps
Vantage Point's senior Salesforce consultants handle permission architecture, duplicate-management design, and data-quality remediation as a standard part of org health work — from a one-time cleanup through managed services for ongoing governance. We bring senior consultants only — no junior handoffs; the experts you meet are the experts who deliver. We've seen every variant of the merge-permission problem, including the regulated-industry version where deletes need an audit trail. If merges, deletes, and duplicates are colliding in your org, our Salesforce advisory team can assess your current model and propose a safe design.
Get Your Duplicate Management Under Control
If your team is weighing merge access, delete risk, or a broader org cleanup, Vantage Point can help assess the right next step and build a practical plan. Start a conversation with our team.
Frequently Asked Questions
Can a user merge records in Salesforce without Delete permission?
No. Merging deletes the non-surviving records, so Salesforce requires object-level Delete permission on the records being merged. There is no separate Merge permission to grant instead.
Do merged records go to the Recycle Bin?
Yes. The non-surviving records from a merge move to the Recycle Bin and can be restored during the bin's retention window, which brings back the record and its relationships. Don't rely on the Recycle Bin as an audit trail, since items age out and it isn't built for reporting.
If I hide the Delete button, can users still delete records?
Yes. Removing the button from layouts and Lightning pages is a UI convenience only. Users who hold Delete permission can still delete through list views, the API, or data tools, so permission assignments are the real control.
What permissions are required to merge accounts in Salesforce?
Merging accounts requires Read, Edit, and Delete on the Account object, plus Edit sharing access to every account in the merge. In private sharing models, the record-access requirement fails more often than the object permission.
Why does a merge sometimes fail even when the user has Delete permission?
The usual causes are record-level sharing (the user can't edit one of the records), portal-enabled contacts on an account, or managed-package triggers that block the delete. Check sharing first, then review any automation on the object.
Is it safe to give sales reps merge access?
It can be, if you treat it as Delete access: grant it through a permission set to a small trained group, pair it with duplicate rules and a review queue, and rehearse in a sandbox. Many orgs instead route merge requests to a data-steward team.
