Post #2

Custom Sharing Reason Available on Standard Objects


Written for founders, business owners, and C-level leaders

Coming next week: A technical guide to custom sharing reasons for Opportunities
Author: Andrew Muzychuk
Date: 11/11/2026
When a deal changes hands in Salesforce, underwriters can lose access mid-review. A custom sharing reason keeps the policy review moving and shows why the team can edit the deal after the handoff.
Written for founders, business owners, and C-level leaders at small and midsize companies in Florida and across the U.S. who rely on Salesforce to keep teams aligned and business-critical work moving.

Consider a $ 2 million commercial policy awaiting approval. During a routine territory change, a new agent takes over the deal. The underwriting team still has to approve the terms, but the transfer removes its access to the deal in Salesforce. In this scenario, the policy sits unreviewed for three to five days while the team waits for access to be restored.

For an operations leader, the question is straightforward. When a deal changes hands, which teams still have work to do? A custom sharing reason such as "Underwriting Review" lets a company tie access to that responsibility. Underwriters can continue their review after the handoff, administrators spend less time restoring permissions, and auditors can see why the team has access.

The Problem (Before Winter '27)

Manatee Consulting’s team needs Edit access to every new business Opportunity so they can attach underwriting notes, set terms, and approve coverage before a policy is bound. Admin maintains an Apex trigger that inserts an OpportunityShare row with RowCause = 'Manual' granting the Underwriting group Edit access whenever an Opportunity is created.

What breaks:
  • Agent transfers (monthly). When a business account is moved to a new agent (territory rebalancing, agent resignation), the Manual share is deleted. Underwriting loses access mid-cycle. A pending $2M commercial policy sits unreviewed for 3–5 days because the underwriter can't see the opportunity. Revenue is delayed.
  • No visibility into why access exists. During a quarterly internal audit, the audit team asks: "Why can the Underwriting group edit 1,200 opportunities across 6 regions?" The sharing page says "Manual" on every single one. The auditor has to interview the original developer (who left 14 months ago) to confirm the intent.
  • Patchy revocation. When the Underwriting team is restructured and split into two sub-teams (Commercial vs. Personal Lines), the admin must remove only the underwriting-related shares while preserving legitimate manual shares a sales manager granted a colleague. They write a one-off SOQL script, run it in production, and accidentally strip a manual share that a VP had granted to a temp worker. The temp loses access mid-quarter.
  • Batch job as safety net. A nightly batch re-scans all open Opportunities and re-inserts missing Manual shares for the Underwriting group. It consumes ~40% of the org's daily API budget on the first of each month (when territory changes are batch-applied) and has caused a production timeout twice.
Annual cost of the problem (estimated):

Item

Cost

Delayed policy binding (avg. 4 days × 30 deals × $5K avg. premium)

~$600K in delayed revenue

Admin time re-sharing & incident response

~160 hrs/yr

Audit prep (reconstructing access rationale)

~3 days per quarter

Nightly batch job for recalculations

???



The Fix (After Winter '27)

Deploy a SharingReason metadata component for Opportunity:
<sharingReasons>
    <label>Underwriting Review</label>
    <fullName>Underwriting_Review__c</fullName>
</sharingReasons>
Update the Apex trigger:
oppShare.RowCause = Schema.OpportunityShare.RowCause.Underwriting_Review__c;
Retire the nightly batch job:
// Retire the nightly batch job

The Outcome

Business metric

Before

After

Measurable benefit

Revenue delays

Underwriting loses access after ownership transfers.

Custom sharing survives ownership changes.

Reduce underwriting interruptions and delayed policy binding.

Administrative effort

Admins manually restore missing shares and investigate access incidents.

No need to recreate shares after ownership changes.

Reduce the current 160 admin hours/year.

Audit preparation

Auditors cannot distinguish business-purpose shares from ordinary manual shares.

Sharing page identifies "Underwriting Review" as the reason.

Reduce the current 12 audit-preparation days/year.

Access management

All programmatic and user-created shares use Manual.

Underwriting shares have a dedicated RowCause.

Eliminate ambiguity when identifying and managing underwriting access.

Production maintenance

Nightly batch scans and recreates missing shares.

Shares persist across ownership changes.

Potentially eliminate the batch job and its associated resource consumption.

Salesforce API consumption

Batch consumes approximately 40% of the daily API budget during peak processing.

No recurring re-sharing required after ownership changes.


Recover API capacity currently consumed by the batch job.


Access revocation

Admins risk deleting legitimate manual shares when removing underwriting access.

Admins can target shares by their specific sharing reason.

Reduce accidental access revocation and related incidents.



Additional strategic benefits

Beyond direct savings, the feature provides several less easily quantified benefits:

  • Business continuity: Underwriting access is no longer dependent on which sales agent owns an Opportunity.
  • Improved governance: Access permissions have explicit business purposes rather than generic Manual labels.
  • Safer administration: Developers and administrators can manage underwriting shares independently of manually granted access.
  • Reduced technical debt: Eliminates the need for custom recovery logic and potentially unnecessary scheduled Apex jobs.
  • Improved scalability: The organization can handle territory changes and ownership transfers without triggering large-scale sharing recovery operations.

Executive business case summary

Manatee Consulting can use Salesforce Winter '27 custom sharing reasons to make its underwriting access management more reliable, transparent, and maintainable.
Previously, the company relied on manually created shares that were deleted whenever Opportunity ownership changed. This created underwriting interruptions, administrative overhead, audit difficulties, and the need for resource-intensive batch jobs to restore access.
With custom sharing reasons, underwriting permissions persist across ownership changes, can be identified by their business purpose, and can be managed independently of ordinary manual shares. This reduces operational risk, potentially eliminates recurring sharing-recovery processes, frees up Salesforce API capacity, and reduces administrative and audit effort.
The key business value is moving from reactive access recovery to persistent, purpose-based access management.

The Agent Left. Who Can Approve the Policy?

Pick a deal that changed owners last month. Ask the new owner who had the next approval. Then ask that person a different question. “When the deal moved to the new agent, could you still open it and sign off?”

If the answer is “I had to message someone,” you’ve found a cost that rarely shows up on a Salesforce report. The deal had an owner. The underwriter knew what to do. The customer still had to wait.

A Handoff CRM Alligators Can Test

For the insurance team in this example, we’d test two changes. First, move an open deal to a new agent and check that the underwriter can still edit the terms. Then move the underwriter off the account and check that their editing access ends. In both cases, a colleague who received separate access from the sales manager should keep it.

That gives you a way to judge the work before approving a wider rollout. Your team can see exactly who can open the deal, who can edit it, and why. If a nightly job has been restoring permissions, those same tests help establish whether it’s safe to retire it.

Bring Us the Deal That Got Stuck

If a recent handoff comes to mind, start there. Tell CRM Alligators what the customer was waiting for and who had to step in. On a Discovery Call, we’ll walk through that handoff with you and identify the first thing worth checking in Salesforce. A deal name and your team’s version of what happened are enough to start.
In one short call, we'll look at your current automation setup, identify
We know how

Book a Discovery Call
with a CRM Alligators Salesforce Architect