6.3 Data Transfer, Ownership, Mass Update, and Mass Delete

Ownership as a data and security control

In Salesforce, owner is more than a name on a record. Ownership can determine who sees the record in private or controlled-by-parent sharing models, who receives workflow tasks, which pipeline appears in forecasts, which list views show records, which dashboards display team results, and who is accountable for follow-up. When a sales representative leaves the company or a service queue is redesigned, ownership changes can alter both operations and security.

Admins usually encounter ownership work in reorganizations. A region is split into two territories, an account executive changes roles, a queue is retired, a partner team takes over a subset of leads, or an inactive user owns thousands of open activities. The wrong tool can create a mess. A single owner change on an account may cascade to related records depending on settings and tool behavior. A bulk update of cases may bypass the intended queue process. A careless opportunity owner change can distort pipeline reporting.

Setup gives admins several mass tools. Mass Transfer Records and Mass Delete Records are found in Setup, with object-specific options and filters. List views can support inline edits or mass actions when the object, field, permissions, and layout allow them. Data Loader is the more flexible option for precise CSV-driven changes, especially when the admin already has record IDs from a report or export. Flow can be appropriate when the business needs repeatable guided logic rather than a one-time CSV operation.

The most important practical habit is to capture record IDs and old values before changing anything. A report export without record IDs is not enough for a reliable rollback. Include owner ID, record ID, key lookup IDs, status, and any fields being changed. If the update affects account ownership, export related opportunities, contacts, cases, activities, account teams, and sharing-related data as needed. The export is the admin's evidence trail.

Mass update and delete judgment

Mass updates should be scoped as narrowly as possible. Filter by object, owner, record type, status, date range, region, and any business field that proves the record belongs in the change set. Then compare the count to the business expectation. If the manager expected 2,400 records and the report returns 8,900, do not proceed. Investigate the criteria. In a high-trust admin workflow, the count reconciliation is as important as the tool selection.

Ownership transfer checklist:

• Confirm the source owner, target owner or queue, object, record type, and active user status.
• Identify related records that should or should not transfer with the parent.
• Review organization-wide defaults, role hierarchy, sharing rules, teams, territories, and queues.
• Decide whether assignment rules, notifications, or automations should run.
• Export current values and save the exact filter criteria used for the change set.
• Test on a small sample and verify visibility as the target user and affected managers.
• Run production changes during a communicated window and validate reports afterward.

Deleting data requires even more discipline. A mass delete may move records to the Recycle Bin, but related records, roll-up summaries, dashboards, integrations, and audit expectations can still be affected. Hard delete bypasses recoverability and should be limited to approved data retention or privacy processes with the right permission and documentation. If a user asks to delete bad import records, the admin should first ask whether they can identify the import batch reliably. A Created Date filter alone may catch legitimate records created during the same time window.

Relationships can block or expand delete impact. Master-detail child records are tied tightly to their parent. Lookup relationships may have delete constraints, clear the lookup, or cascade depending on configuration. Files, activities, campaign history, tasks, and junction objects can carry business context that users still need. Before deleting, inspect the relationship model in Object Manager and test what happens to related records in a sandbox or noncritical sample.

Inactive users create common scenario traps. Records can remain owned by inactive users, and reports may still include them. A new user cannot simply inherit another user's records unless the admin transfers them. But reassigning every record from an inactive user may be wrong if closed opportunities, historical cases, and completed tasks should remain historically accurate. A common pattern is to transfer open work and current accounts while preserving closed history for audit and performance reporting.

Study trap: do not confuse visibility repair with ownership change. If a manager cannot see records, changing every owner to the manager is usually wrong. Check role hierarchy, sharing rules, teams, territories, queues, and permissions first. Ownership is powerful because it controls accountability; use it when accountability should change, not merely because a report looks incomplete.