Skip to content
SteveTechArcSteveTechArc Courses

Who Holds the Key to Each Record

Module 3 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Once a cabinet is locked, who holds the first key to each record, and what happens to that key when the record moves to someone else?

Here’s a question I ask in class. An object is Private. Grant Access Using Hierarchies is off. There are no sharing rules. Who gets to see the records?

The owner. The owner and only the owner. That’s your starting point for security, the foundation we build on. (And anyone with View All or Modify All, who goes around the share table altogether. Module 1 covered them.)

Remember the Runway object from module 2. It went Private, and the pilot and the manager could open the tab but saw no records. Now, as admin, I change the owner of one runway to the pilot. The pilot logs in and sees a single record: the one the pilot owns. Ownership is way 3, and it’s the first key.

The owner gets full access

Section titled “The owner gets full access”

On most objects, every record has an owner, in its Owner field. And the owner doesn’t just get read/write. The owner gets what’s called full access, which is read/write and something above that. Salesforce: “Record ownership and full access are synonymous and interchangeable and provide the user with the highest level of access to a record” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07).

What’s above read/write? Sharing the record, transferring it, deleting it. Module 2 showed this: even on a Public Read/Write object, only the owner can change the sharing or delete the record.

But full access is in the cabinet, not the office. The owner still needs the object. “The owner has access to the record, based on the Object Settings for the owner’s profile.” Salesforce’s example: an owner with Create and Read but not Edit or Delete “can create a record for the object and see the new record. However, the owner won’t be able to edit or delete it” (Platform Sharing Architecture). The most restrictive wins, even for the owner.

So the owner needs Read on the object. Salesforce enforces it when you change the owner: “The new owner has at least the Read permission on the object” (Transfer Records (opens in a new tab), Salesforce Help, checked 2026-11-07).

Not every object has an owner

Section titled “Not every object has an owner”

Not all objects have an Owner field, and people miss this. Custom objects have one, unless they’re the detail in a master-detail relationship. Many standard objects have one: accounts, contacts, cases. But some standard objects that are more like reference data don’t.

Take products. The product object, Product2, has no Owner field (Product2 (opens in a new tab), Object Reference for the Salesforce Platform, Winter ‘27, API version 68.0, checked 2026-11-07). So if you’re planning owner-based security on products, you can’t do it. I’ve seen people design solutions where they try to give products the same kind of ownership and sharing as accounts, and it won’t work. What users can do with products comes from their object permissions and from price books, which have their own defaults (module 2).

And a detail record in a master-detail relationship has no owner of its own. Its parent’s owner decides, which is why its default is Controlled by Parent. Module 6 takes that apart.

So before you design ownership into an object, open it in Object Manager and look for the Owner field. No owner, no ownership-based sharing.

A record moves: what goes with it

Section titled “A record moves: what goes with it”

Records change hands all the time. A rep leaves, territories are redrawn, a case is escalated. Each time, the key moves. Here’s what you need to know.

Who can transfer one record. Salesforce lists the conditions: you have Edit, and “You’re the record owner or above the record owner in the role hierarchy. Or, you have the Modify All Data permission or the Modify All Records permission for the given object.” And if the object’s default is “Public Full Access or Public Read/Write/Transfer, all users can transfer ownership of that type of record” (Transfer Records). Moving many records at once takes the Transfer Record permission and the Mass Transfer tool or a list view (same page).

The hierarchy access moves. The managers above the old owner lose the access they had through the hierarchy, and the managers above the new owner gain it. Module 1 showed what that costs when many records move.

Manual shares go, by default. In a video I made to answer a student’s question, I shared a record with one user by hand, then changed its owner. The share was gone: manual shares are deleted on change of owner. That’s still the default. “By default, when ownership of a record is transferred, Salesforce deletes manual shares on the record, which can cause users to lose record access.” Since Winter ‘27 you can turn on Keep manual shares when transferring records on the Sharing Settings page (Keep Manual Shares When Transferring Records (opens in a new tab), Salesforce Help, checked 2026-11-07; Winter ‘27 release note (opens in a new tab), checked 2026-11-07). Chapter 5, module 4 covers the decision.

Rules and code follow their own reasons. Sharing rules are worked out again for the new owner, and Apex sharing with its own sharing reason stays. Chapter 5, modules 3 and 6 showed both.

What changes when a record changes owner What changes when a record moves to a new owner. Moves with the owner: the new owner gets full access, and the managers above the new owner get access through the hierarchy, while those above the old owner lose it. Goes, unless you keep it: manual shares are deleted by default; since Winter '27 an org setting can keep them. Follows its own reason: sharing rules are worked out again, and Apex sharing with its own reason stays. Footnote: the new owner needs at least Read on the object. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Moves with the owner ownership and the hierarchy The new owner gets full access Managers above the new owner gain it Managers above the old owner lose it Goes, unless kept manual shares Deleted by default Kept if the org setting is on (Winter '27) Follows its own reason rules and code Sharing rules are worked out again Apex sharing with its own reason stays The new owner needs at least Read on the object. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Way 4: queues

Section titled “Way 4: queues”

A record doesn’t have to be owned by a person. “Every record must be owned by a single user or a queue” (Platform Sharing Architecture). A queue owns work that a team shares, before anyone picks it up.

“Queues help you prioritize, distribute, and assign records to teams who share workloads. Queue members and users higher in a role hierarchy can access queues from list views and take ownership of records in a queue.” And “Queues are available for cases, contact requests, leads, orders, custom objects, service contracts, and knowledge article versions” (Sharing and Record Access Features (opens in a new tab), Salesforce Help, checked 2026-11-07).

Think of a support queue. The cases sit in it, and the people in the queue can see them. When one of them takes ownership, the case leaves the queue. It’s theirs now, and the others see it only if another way gives it to them. That’s different from a case team, which stays on the record whoever owns it. Chapter 9 covers teams.

Who can be in a queue. “Members can be individuals, roles, public groups, territories, connections, or partner users,” and “Guest users can’t be queue members” (Create Queues (opens in a new tab), Salesforce Help, checked 2026-11-07). If you add a role and its subordinates, everyone in that role and below is a member. Watch partner users: a queue can hand records to people outside your company. Salesforce gives one warning for older orgs: in orgs created before February 8, 2024, records open to Roles and Subordinates “become available to Roles, Internal and Portal Subordinates when you enable digital experiences.” Review those queues and use Role and Internal Subordinates where you mean only your own people (same page).

Each queue has its own hierarchy switch. “To allow automatic access to records using your role hierarchies, select Grant Access Using Hierarchies. When selected, any records shared with users in this queue are also shared with users higher in the hierarchy.” The object’s setting still wins: turn it off for the object on the Sharing Settings page, and its records “aren’t shared with users higher in the hierarchy, even if you enable Grant Access Using Hierarchies for the queue” (Create Queues).

And an org setting for new queues. Grant access using hierarchies by default in new queues, on the Sharing Settings page, “controls the default value of the queue-level setting.” It “doesn’t affect existing queues,” and queues in installed packages that target API version 66.0 or earlier come with the setting turned off (Grant Access Using Hierarchies by Default in New Queues (opens in a new tab), Salesforce Help, checked 2026-11-07).

So for every queue, decide: should the managers of the people in it see what’s waiting? For a sales lead queue, maybe yes. For an HR complaints queue, probably not. Module 5 comes back to that one.

Who sees a record, by who owns it Who sees a record, by who owns it. Owned by a user: the owner has full access, and the managers above the owner in the role hierarchy see it when Grant Access Using Hierarchies is on for the object. Owned by a queue: the queue's members see it and can take it, and the managers above the members see it only when the setting is on for the object and for the queue. Footnote: every record has one owner, a user or a queue; some objects have no owner at all. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} A record one owner Owned by a user the owner: full access Managers above the owner if the hierarchy is on for the object Or owned by a queue its members see it and can take it Managers above the members only if on for the object and the queue owner role hierarchy owner role hierarchy Every record has one owner, a user or a queue. Some objects have no owner at all. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

When one owner owns too much

Section titled “When one owner owns too much”

One more thing about owners. It’s the role and who’s above them that counts, not the Manager field on the user. And every record an owner holds is cascaded up their branch.

So what happens when one user owns a huge number of records, like an integration user loading data, or a placeholder owner for unassigned accounts? Salesforce calls it ownership skew, and gives a line: “If a single user owns more than 10,000 records,” then “The user record of the owner should not hold a role in the role hierarchy,” or, if it must, “put the role at the top of the hierarchy in its own branch” (Platform Sharing Architecture). Chapter 22 covers skew in depth. For now, know that who owns a record is a performance decision as well as a security one.

What an architect decides here

Section titled “What an architect decides here”
  • For every object, whether it has an owner, and if not, how its records are shared instead.
  • Who owns each kind of record: a person, a queue, or a system user, and for system users, where they sit in the hierarchy.
  • That every owner has at least Read on the object, so a transfer doesn’t fail or hand over a record nobody can open.
  • Whether manual shares should be kept when records change owner, for the whole org.
  • For every queue, its members, whether any are partner users, and whether the managers above them should see its records.
  • The default for new queues, set on purpose, not left as it came.

Beyond the exam: what AI changes. When an agent creates records, its user owns them. An agent that logs thousands of cases or leads becomes one of the biggest owners in the org, with all the questions above: where its user sits in the hierarchy, who sees everything it owns, and whether it should hand its work to a queue instead. Decide its ownership before it goes live, not after it owns 10,000 records.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.