3. Full Article
Changing the owner of a Salesforce record has often produced an unwelcome second change: colleagues who received access through manual sharing could lose it.
Winter '27 gives Salesforce administrators a new choice. The org-level Keep manual shares when transferring records setting can preserve those shares when ownership changes. That can protect continuity during account reassignments, case handoffs, fundraising portfolio changes, and other transfers.
It can also preserve access after the original reason for that access has expired.
That is why this feature should be treated as an access-lifecycle decision, not a release-note checkbox. The right question is not simply whether retained shares are convenient. It is whether your organization can explain, review, and revoke the access that survives a transfer.
What changed in Salesforce Winter '27?
Salesforce's default behavior is to delete manual shares when a record's owner changes. The practical effect can be immediate: a user who depended on a manual share may no longer see or work with the record after the transfer.
Winter '27 adds an org-level setting under Setup > Sharing Settings > Organization-Wide Defaults. When Keep manual shares when transferring records is enabled, Salesforce retains manual shares through an ownership change. The setting is available in Lightning Experience and Salesforce Classic for Professional, Enterprise, Performance, Unlimited, and Developer editions.
Salesforce left the setting disabled by default, preserving existing behavior until an administrator makes a deliberate change. That is sensible. Retention and deletion solve different problems:
- Deleting shares limits access that was associated with the previous ownership context, but it can interrupt valid collaboration.
- Retaining shares protects continuity, but it can leave users with access after the business relationship, assignment, or temporary need has ended.
Neither behavior is inherently correct for every organization.
Why ownership transfers cause more than an administrative problem
Ownership changes are rarely isolated technical events. They often represent a business transition: a new territory, a departed employee, a reorganized service team, an acquired organization, a reassigned donor portfolio, or a claims workload shift.
The transfer itself may succeed while the business outcome fails.
A colleague might lose access to an open service case. A subject-matter expert might disappear from a complex opportunity. A fundraiser supporting a major gift could lose the donor record. Conversely, someone who helped temporarily might continue to see sensitive records after the work has ended.
Salesforce access is layered. Object permissions, field permissions, organization-wide defaults, role hierarchy, sharing rules, teams, territories, restriction rules, and manual or programmatic shares can all affect what a person can see and do. A retained manual share changes only one part of that model. It does not replace the need to understand the complete effective access path.
The decision: continuity or automatic cleanup?
Use three questions to make the initial choice.
1. Does the need for access normally survive ownership?
Retention is a stronger candidate when the collaborator's business responsibility continues after the owner changes. Examples include a clinical operations specialist supporting a case, a claims expert assigned across ownership changes, or a major-gifts leader who remains accountable for a donor relationship.
Deletion may be safer when the share is closely tied to the former owner's team, territory, project, or short-term coverage arrangement.
2. Is manual sharing the right access mechanism?
Manual sharing is useful for exceptions. It becomes harder to govern when it carries a repeatable operating model.
If the same type of user repeatedly needs access for the same reason, consider whether a team, sharing rule, territory, restriction rule, or carefully designed programmatic approach describes the requirement more clearly. Salesforce's architecture guidance explicitly warns that no single sharing model fits every org. The goal is not to eliminate manual shares; it is to reserve them for needs that are genuinely exceptional.
3. Can you remove retained access reliably?
Enabling retention removes one automatic cleanup event: owner transfer. Something else must tell the organization when access should end.
That control might be a defined case-closure process, assignment end date, employee-role change, project completion, donor-stage transition, or periodic access review. If no owner, trigger, evidence, or service-level expectation exists for revocation, retention creates an open-ended access decision.
A six-step readiness plan before enabling the setting
Step 1: Discover where manual shares matter
Start with the business processes most likely to transfer ownership: Accounts, Contacts, Opportunities, Cases, donor or grant records, claims-related custom objects, and sensitive service records.
For each object, identify:
- who creates manual shares;
- whether automation or integrations create share rows;
- which users and groups receive access;
- whether shares are routine or exceptional;
- which ownership changes occur through the user interface, API, Flow, Apex, data loads, or third-party tools; and
- which downstream records or customer journeys depend on that access.
Do not infer usage from configuration alone. Sample real transfer scenarios and review effective access before and after them.
Step 2: Classify each share by purpose and lifetime
For a representative sample, document the business reason, sensitivity, expected duration, accountable owner, and revocation event. A simple classification is enough:
- Persistent collaboration: access should normally survive transfer.
- Owner-context access: access should end when ownership changes.
- Time-bound exception: access may survive a transfer temporarily but needs a separate end condition.
- Unexplained: no current owner can justify the share.
The unexplained category is a remediation queue, not an argument for blanket retention or blanket deletion.
Step 3: Redesign repeatable access before preserving exceptions
Look for manual shares that are compensating for a missing role, rule, team, or process. Move stable, repeatable requirements into the most appropriate governed mechanism. Keep manual sharing for real exceptions.
This step reduces the number of decisions the new setting must carry and makes post-transfer access easier to explain.
Step 4: Test complete transfer journeys in a sandbox
Test the setting both disabled and enabled. Use representative personas, volumes, record types, automation, and sensitive data. At minimum, cover:
- a single record transfer in the user interface;
- a transfer through Flow, Apex, API, or an integration used in production;
- a bulk ownership change or territory realignment;
- transfer of an Account with relevant Contacts, Opportunities, and Cases;
- a change to the parent Account for a child record;
- users with object access but different field-level access;
- internal, partner, and customer personas where they are part of the process;
- deactivation or role change of the former owner; and
- the intended revocation event after transfer.
For every scenario, record four outcomes: who can see the record, who can edit it, which sensitive fields remain visible, and whether the business transaction can be completed. A successful save message is not proof of correct access.
Step 5: Establish review, revocation, and evidence
Assign an owner for the policy and for operational cleanup. Define how retained shares are reviewed, how exceptions are approved, how stale access is removed, and what evidence is retained.
The cadence should reflect the risk and rate of change in the process. A high-volume claims or service operation may need event-driven cleanup and frequent exception review. A low-volume major-gifts process may use a scheduled review tied to portfolio governance. The correct interval is a risk decision, not a universal Salesforce setting.
Step 6: Roll out with monitoring and a rollback path
Enable the setting through normal change governance. Communicate the changed behavior to administrators, data teams, sales operations, service operations, and integration owners. Monitor access-related support cases, transfer jobs, unusual share growth, and failed revocation processes.
If the results diverge from the sandbox baseline, pause mass transfers and investigate before expanding the rollout. Changing the setting back affects future transfer behavior; do not assume it automatically cleans up shares already retained.
Industry-specific implications
Healthcare
Care coordination and service continuity can justify access that outlives record ownership. At the same time, HHS guidance requires role-based policies that limit workforce access to protected health information where the HIPAA minimum-necessary standard applies. Retention should therefore be linked to a documented job need and a reliable end condition. This article is operational guidance, not a HIPAA determination.
Insurance
Claims, policy servicing, underwriting, appeals, and producer relationships commonly cross teams. A transfer may need to preserve expert or supervisory access, but indefinite retention can expand the audience for nonpublic information. Insurers should assess the setting against their own legal obligations, information-security program, state requirements, and internal access policy with qualified counsel and security teams.
Nonprofit foundations
Donor, grantee, program, and major-gift records often involve collaborative relationships that survive a portfolio reassignment. Manual shares can protect that continuity. They can also leave former campaign teams, temporary staff, or cross-functional contributors with access after their role ends. Tie retention to stewardship responsibilities and review it when assignments, employment, or grant stages change.
A practical go/no-go scorecard
Enable the setting only when most of these statements are true:
- We know which high-value objects and processes depend on manual shares.
- We can distinguish lasting collaboration from access tied to the former owner.
- Repeatable access has been moved to more appropriate sharing mechanisms where feasible.
- We tested UI, automated, API, and bulk transfers with representative personas.
- We validated field-level as well as record-level outcomes.
- Every retained-access pattern has an accountable owner and revocation event.
- We can review and remove stale shares.
- We have a monitored rollout and an incident path.
If several answers are no, keep the default behavior while you remediate the access model. That may leave a continuity problem to solve, but it avoids converting an understood deletion event into unmanaged persistence.
Make the setting part of a governed access model
Winter '27 removes a rigid platform constraint. It does not decide whether a user should still have access after a record changes hands.
That decision belongs to the organization. The most defensible approach begins with business purpose, uses the right Salesforce sharing mechanism, tests the complete transfer journey, and proves that access can be removed when the purpose ends.
Yuniq's Salesforce consulting and managed support services include customization, implementation support, integration, validation, and ongoing platform support. Yuniq can help organizations inventory ownership-transfer workflows, test effective access, and turn the new setting into a governed remediation plan. Start with a focused Salesforce sharing and record-transfer assessment before changing the org-wide behavior.
