Straight answer: Setup has a Mass Transfer Records tool for accounts, leads and custom objects, and it is fine for hundreds of records and wrong for hundreds of thousands. Ownership is not a field like any other. Changing it rewrites sharing, fires automation, deletes manual shares and can take hours of background recalculation on a large object. Plan a big transfer as a change window, not as an afternoon’s admin.
The tool
Setup, Data, Mass Transfer Records. Pick the object, pick the existing owner and the new owner, add criteria to narrow the set, and run it. Approval requests have their own separate mass transfer tool.
The account screen has extra checkboxes, because transferring an account can pull related records with it: open and closed opportunities, cases, and so on. Read them carefully. Transferring closed opportunities changes historical reporting by owner, which someone in finance notices at quarter end.
The user running it needs the Transfer Record permission along with access to the records themselves.
What changes when ownership changes
- Role hierarchy sharing. Everyone above the old owner in the hierarchy loses access. Everyone above the new owner gains it. On an account this cascades to the contacts, opportunities and cases underneath.
- Manual shares are deleted. Any share created by hand or by a sharing button on the record is removed when the owner changes, and it does not come back.
- Automation fires. Record-triggered flows and triggers run on the update, so anything keyed on the owner runs for every record in the transfer.
- Validation rules apply. A record that fails a rule added since it was created will block its own transfer, which is how a run of fifty thousand ends up at forty-eight thousand with a list of errors.
- Reporting by owner shifts retrospectively. There is no ownership history, so last quarter’s report now attributes those records to the new owner.
The recalculation cost
Sharing is stored, not computed on the fly. Changing an owner means the platform rewrites share rows for that record and everything beneath it, then re-evaluates sharing rules that reference the owner.
On a small set that is instant. On a large set it runs in the background for a long time, the org is slower while it does, and access can look briefly inconsistent. Locking is the other risk: parallel updates touching the same parent records contend and produce row lock errors.
Practical mitigations, in the order worth trying:
- Run it out of hours. This is most of the answer.
- Break the work into batches grouped by parent, so two batches never touch children of the same account at once.
- Use serial rather than parallel processing in the Bulk API for owner updates. It is slower per batch and finishes sooner overall because nothing retries.
- For genuinely large reorganisations, ask Salesforce about deferring sharing calculation for the duration, which turns many small recalculations into one at the end.
When to use the data loader instead
The Setup tool is limited in the criteria it accepts and gives you no file of what it did. For anything you would want to audit or reverse, extract the record IDs and current owners to a file, load the new owner with the data loader, and keep the extract.
That extract is your undo. It is the only undo, because there is no ownership history to roll back to.
Ownership skew
Concentrating records under one user creates its own problem. Once a single user owns tens of thousands of records on an object, every recalculation involving that user’s position in the hierarchy becomes expensive, and updates to those records contend for the same rows.
The usual cause is an integration user or a data steward account that has become the default home for anything orphaned. If a transfer is about to park a large volume under one user, spread it across several, or use a user outside the role hierarchy so the hierarchy has nothing to recalculate.
Frequently asked
What happens to records owned by a deactivated user? They stay owned by that user. Deactivation does not transfer anything, and the records remain reportable and accessible through sharing rules. Transfer them before deactivating if anyone needs to work them.
Does mass transfer send email notifications? The tool has an option to notify the new owner, and record-triggered automation may send its own. Check both before running anything large, or your reorganisation announces itself several thousand times.
Can I transfer records to a queue? Not with this tool. Queue assignment is an owner change to the queue ID, which you can do with the data loader on objects that support queues.
