Skip to content
SteveTechArcSteveTechArc Courses

Every Way Side by Side

Module 6 of 6 in the chapter Config-Based Sharing: Manual Shares, Teams and Territories, chapter 9 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When a record changes owner, which of the ways that gave people access keep working, which ones move, and which ones are deleted?

A student in one of my classes asked a question I couldn’t answer on the spot. If you write Apex sharing on a standard object, and the only sharing reason you’re allowed to use is Manual, won’t those shares be lost when the owner changes?

I wasn’t sure. So I spun up an org with three users and tried it. A manual share: gone when the account moved to the other user. An Apex share with the Manual reason: also gone. Then I tried a team member added by code, thinking a team might survive. Gone too. Neither one survived the owner change.

That was then. Some of the answers have changed since, and that’s why this module exists: every way, side by side, with today’s answer.

Three kinds of answer

Section titled “Three kinds of answer”

When the owner changes, each way of sharing does one of three things.

  • It moves with the owner. The access was about who owns the record, so it follows the new owner.
  • It goes, unless you keep it. The access was granted by the old owner or on their behalf, and Salesforce deletes it by default. For some ways you can now choose to keep it.
  • It stays. The access was never about the owner, so the owner change doesn’t touch it.
What survives an owner change What survives an owner change. Moves with the owner: the new owner's full access; the role hierarchy above the new owner, while the managers above the old owner lose access; owner-based sharing rules, re-evaluated; the account owner's access to the account's contacts, opportunities and cases, set by the owner's role. Goes, unless you keep it: manual shares, kept only if Keep manual shares when transferring records is on; Apex or flow shares with the Manual sharing reason, the same rule; account team members, kept with Keep account team only if the owner, someone above them or an admin added them; opportunity team members, kept with Keep Opportunity Team. Stays: criteria-based sharing rules, unless they read the owner; shares with a custom sharing reason; territory assignment, which follows the account's fields and the rules. Footnote: test it with three users: the old owner, the new owner, and the person who should keep or lose access. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-03", "id": "DGM-SVA-TT-11", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Moves with the owner it was about the owner The new owner's full access The role hierarchy above the new owner Owner-based rules, re-evaluated The owner's access to the account's children Goes, unless you keep it deleted by default Manual shares: keep with the org setting Apex or flow shares with the Manual reason Account team: Keep account team; who added them matters Opportunity team: Keep Opportunity Team Stays never about the owner Criteria-based rules, unless they read the owner Shares with a custom sharing reason Territory assignment Test it with three users: the old owner, the new owner, and the person who should keep or lose access. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Moves with the owner

Section titled “Moves with the owner”
  • The owner’s own access. The new owner gets full access; the old owner keeps only what some other way gives them (chapter 6, module 3).
  • The role hierarchy. The managers above the old owner lose access, and the managers above the new owner gain it (chapter 6, module 3; chapter 8, module 4).
  • Owner-based sharing rules. “When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). A rule on “owned by region 1” stops sharing the record; a rule on “owned by region 2” starts (chapter 8, module 3).
  • The account owner’s access to the account’s children. That access is set by the owner’s role (chapter 10 covers it), so it changes with the owner.

Goes, unless you keep it

Section titled “Goes, unless you keep it”
  • Manual shares. “By default, if a record owner changes, Salesforce deletes any manual shares on the record, which can cause users to lose access,” and the org-level setting Keep manual shares when transferring records changes that (Manual Sharing Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). Module 1 has the cases around accounts and their children.
  • Apex and flow shares with the Manual sharing reason. This is my class question. On a standard object, code that writes a share with the Manual reason is a manual share, and it goes with the owner change, just as my demo showed. Chapter 5, module 6 has the fix that came this year: custom sharing reasons on standard objects. Salesforce’s Developers blog says they “will reach all orgs by the end of October,” and with one, “Salesforce doesn’t delete them when the owner changes” (Protect Apex Shares: Custom Row Causes on Standard Objects (opens in a new tab), Salesforce Developers blog, checked 2026-11-07).
  • Account team members. “To keep account team members with an account when the owner changes, select Keep account team.” But “This action only applies to team members added by a Salesforce admin, the account owner, or someone higher in the role hierarchy. Team members added by users with group-based access are removed even if Keep account team is selected” (Considerations for Changing a Record’s Owner (opens in a new tab), Salesforce Help, checked 2026-11-07). In my demo the team member went, and today that’s still what happens unless someone keeps the team. Module 2 has the details.
  • Opportunity team members. “Opportunity team members only when the Keep Opportunity Team option is selected” (same page), and, under a Private default, Retain Edit Rights for Previous Owner keeps the old owner’s Read/Write (module 2).

Stays

Section titled “Stays”
  • Criteria-based sharing rules. They read the record’s fields, not its owner, so the record stays shared as long as it matches. The exception is a rule that reads the owner field, which chapter 8, module 3 says not to write.
  • Shares with a custom sharing reason. On custom objects that’s always been true, and in my demo I said so: with a custom share reason, “it would survive ownership change.” Now the same is true on standard objects that use one.
  • Territory assignment. Accounts go into territories by assignment rules on the account’s fields (module 3). An owner change on its own doesn’t move the account, unless a rule reads the owner.
  • Compliant Data Sharing participants. The participant is on the record, not on the owner. Salesforce documents one quirk: a participant who becomes the owner and is then removed as owner loses access until their participant record is deactivated and reactivated (module 5).

An account carries its family

Section titled “An account carries its family”

An account owner change is bigger than one record. Salesforce lists what moves with it (Considerations for Changing a Record’s Owner):

  • Automatically: contacts the old owner owns, the old owner’s open opportunities, contracts that are Draft or In Approval, Draft orders, and the old owner’s open activities.
  • Only if you select it: open opportunities owned by others, the old owner’s closed opportunities, open cases or all cases, closed cases, Keep account team, and Keep opportunity teams with transferred opportunities.

And every record that moves is another owner change, with everything above happening to it as well.

What moves with an account What moves with an account. Automatically: contacts the old owner owns; the old owner's open opportunities; contracts in Draft or In Approval; Draft orders; the old owner's open activities. Only if you select it: open opportunities owned by others; the old owner's closed opportunities; open cases, or all cases; closed cases; Keep account team; Keep opportunity teams with transferred opportunities. Footnote: an opportunity whose owner changes because its account changed owner doesn't run flows or Apex triggers. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-03", "id": "DGM-SVA-TT-12", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Automatically moves with the account Contacts the old owner owns The old owner's open opportunities Draft or In Approval contracts Draft orders The old owner's open activities Only if you select it an option on the transfer Open opportunities owned by others The old owner's closed opportunities Open cases, or all cases; closed cases Keep account team Keep opportunity teams An opportunity whose owner changes because its account changed owner doesn't run flows or Apex triggers. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

When your automation doesn’t run

Section titled “When your automation doesn’t run”

Here’s the part I want architects to notice. In my video, the fix for Apex shares on standard objects was a trigger: listen for the change of owner, and put the shares back. That still works for a record whose owner is changed directly.

But not for everything that moves with an account. When opportunities change owner because their account did, Salesforce says: “The opportunity owner change doesn’t invoke any automations, such as flows or Apex triggers, because it cascades from an account owner change” (Considerations for Changing a Record’s Owner).

So a trigger on the opportunity that rebuilds its shares won’t fire for those opportunities. That’s one more reason to use a custom sharing reason instead of putting shares back by hand.

Test it with three users

Section titled “Test it with three users”

It takes three users to test this properly: the old owner, the new owner, and the person who should keep or lose access. Change the owner on the screen, through a mass transfer, through your integration, and through an account transfer that carries opportunities with it. Then check the third user each time. Chapter 13 covers testing.

What an architect decides here

Section titled “What an architect decides here”
  • For every way your org shares a record, which of the three answers it gets on an owner change, and whether that’s what the business means.
  • Whether Keep manual shares when transferring records is on for the org.
  • For code and flows that write shares on standard objects: a custom sharing reason, not Manual.
  • Who adds team members, so Keep account team actually keeps them, and when Keep Opportunity Team and Retain Edit Rights for Previous Owner are used.
  • Which account transfers carry opportunities, cases and teams, and that no share depends on a trigger that a cascaded change won’t run.
  • The three-user test for every way that changes owners: the screen, mass transfer, integrations and agents.

Beyond the exam: what AI changes. Agents reassign records: cases to whoever is free, accounts after a reorganization, leads to the right rep. Every one of those is an owner change, with every rule in this module behind it. Before an agent transfers records, know which shares go with the old owner, and make sure nothing your sharing model needs depends on a trigger that a cascaded change won’t run. Chapter 20 covers agents.

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.