An account executive needs to see a renewal account owned by customer success, but changing the account owner would disrupt handoffs. Salesforce sharing rules can give that executive access without changing ownership.
The setup works best when you start with a clear access request: which records, for whom, and at what level? First, check the permissions already in place. Then choose a rule that grants only the additional visibility your team needs.
How Salesforce sharing rules fit the access model
Start with the baseline, not the exception
Salesforce uses organization-wide defaults to set baseline record access for an object. If Opportunity access is Private, reps generally need another route to opportunities they don’t own. A role hierarchy, opportunity team, territory assignment, or sharing rule may provide that route.
Check Setup > Sharing Settings before building anything. Review the object’s default internal access and the roles and groups already involved. A sales manager might already see a rep’s opportunities through the role hierarchy. Adding a rule for that manager would create another access path without solving a real gap.
Salesforce’s overview of sharing rules explains how rules make automatic exceptions to organization-wide defaults.
Know what a rule cannot change
Sharing rules extend record access; they do not restrict it. If an SDR already sees every account because of broad access elsewhere, a narrower sharing rule won’t hide accounts outside that SDR’s territory. Review the existing access path instead.
Record visibility is also different from permission to use an object or field. A shared Opportunity won’t help someone who lacks Opportunity Read permission. Likewise, record Edit access doesn’t grant permission to edit a field hidden or restricted by field-level security. Keep these controls separate when planning and troubleshooting.
Choose owner-based or criteria-based sharing
The choice depends on how you identify the records. Salesforce’s sharing rule types distinguish rules based on record ownership from those based on field values.
Use owner-based rules when the owning team defines the scope
An owner-based rule selects records owned by a specified set of users, roles, or groups, then shares them with another audience. Suppose your SDRs own incoming Leads, but account executives need to review those Leads before a handoff. An owner-based Lead rule can share records owned by the SDR group with the AE group.
This design fits a stable team-to-team relationship. It becomes harder to manage if ownership frequently shifts for reasons unrelated to the access requirement. Check group membership as carefully as the rule itself: adding a user to the source group could change which records qualify, while adding one to the receiving group could expand the audience.
Use criteria-based rules when a record field defines the scope
A criteria-based rule selects records using field conditions, regardless of who owns them. For example, if an Account field consistently identifies an approved coverage segment, you could share matching accounts with a specialist group.
The field must be suitable for sharing criteria on that object. Available fields and operators vary, so inspect the choices in your org before promising access based on a particular field. Criteria also depend on data quality. A rule based on a blank or inconsistently maintained segment field won’t reliably reflect the coverage plan.
Plan the access request before opening Setup
Name the records and recipients
Write the request as a sentence: “Give the renewals group Read access to Accounts owned by the customer success group.” That tells you the object, source, audience, and access level. It also gives you a test case after saving.
Be precise about recipients. A public group can be useful when a working team doesn’t match one Salesforce role. A role-based recipient may fit a straightforward management structure. If the need applies to one deal or one account, consider whether an account team, opportunity team, or manual share fits better than an automatic rule covering many records.
Decide between Read Only and Read/Write
Read Only is often enough for forecast inspection or handoff preparation. Read/Write may be appropriate when a receiving team must update the shared records as part of its job. Choose based on the action people must perform, not their seniority.
Before selecting either level, confirm the users’ object and field permissions. Also identify related records they expect to use. Seeing an Account doesn’t automatically prove a rep can complete every task involving its Contacts or Opportunities.
Test the business task, not only whether the record page opens.
Create Salesforce sharing rules in Setup
The exact choices depend on the selected object and your org’s configuration. Use a sandbox first when your release process supports one, especially for rules that could expose customer or commercial data to a broad group.
Open the object’s sharing rule settings
Salesforce documents the sharing rule creation process. In Lightning Experience, follow this sequence:
- In Setup, enter Sharing Settings in Quick Find and open Sharing Settings.
- Find the Sharing Rules section for the object, such as Account, Lead, or Opportunity, and select New.
- Enter a clear label and rule name. Add a description that records the business reason and intended audience.
- Select Based on record owner or Based on criteria, then define the source records using the options shown.
- In the sharing section, choose the receiving group, role, or other available recipient and set the access level. Review the full rule before saving.
Use names that remain understandable after a reorganization. “Share CS-owned Accounts with Renewals” tells a future admin more than “Account Rule 2.”
Complete the fields for your chosen rule type
For an owner-based rule, choose whose owned records qualify and who receives them. Salesforce’s owner-based rule instructions are useful when checking the source and recipient choices.
For a criteria-based rule, select a field, operator, and value for each condition. Check that the condition matches actual records, including any blank or unexpected values. Then choose the recipients and access level.
Save the rule and allow access recalculation to complete before judging the result. Don’t assume every user sees a change immediately, particularly when an object has many records or sharing updates are still processing.
Verify access with representative revenue users
Run both allow and deny tests
An administrator’s view won’t prove what an AE or SDR can do. Test with a representative non-admin user who has the intended license, role, profile, permission sets, and group memberships. When practical, use a sandbox account configured like the real role.
For each rule, select at least one matching record the user should access and one nonmatching record they should not. Check the intended action, such as opening an Account or editing an Opportunity. Then check a report, list view, and search result that the team uses. Include connected tools or API processes if they rely on the same access.
A passing test needs both sides: the right records appear, and unrelated records remain outside the user’s expected scope.
Diagnose the permission layer that failed
If a rep cannot open a shared record, confirm the rule’s source conditions and recipient membership. Then check whether the user has the object’s Read permission and whether another sharing change is still processing.
If the record opens but a field cannot be edited, investigate object permissions, record Edit access, and field-level security. Profiles, permission sets, permission set groups, and muted permissions can all affect the user’s effective permissions. A layout change alone isn’t a field security fix.
If the user sees too much, trace every access path. Broad object permissions, role hierarchy, group membership, territory access, teams, and other sharing can overlap. Removing one rule won’t take away access granted elsewhere.
Maintain sharing rules as the sales motion changes
Account for recalculation and rule volume
Changing a rule can add or remove access across many records. Schedule broad changes with enough time to recalculate and test before a forecast review or territory launch. Salesforce’s guidance on editing sharing rules describes recalculation behavior.
Don’t create a separate rule for every individual exception. That makes access difficult to explain and maintain. Reusable groups and clear ownership policies help keep the setup manageable, but only when group membership has an owner and a review process.
Review changes to teams and data
A rule can stay unchanged while its effect shifts. A new AE joins a receiving group. An integration starts populating the field used by a criteria-based rule. Customer success takes ownership of a new class of accounts. Each change can expand access without anyone editing the rule.
Review relevant rules after role changes, territory redesigns, new integrations, and changes to sensitive fields or sales processes. Keep the access request and test cases with your change records. A scheduled review with sales and RevOps owners can catch groups that no longer match real responsibilities.
Key takeaways
- Salesforce sharing rules grant additional record access; they cannot remove access a user already has.
- Choose owner-based rules for records defined by their owners and criteria-based rules for records defined by field values.
- Confirm object and field permissions separately, then test allowed and denied access as representative users.
- Recheck rules when group membership, ownership, or qualifying data changes.
Frequently asked questions
Can a sharing rule make Accounts visible but prevent edits?
Yes, choose Read Only when the rule should grant viewing access without granting record editing through that rule. However, users may still have edit access through another route. Their object and field permissions also affect what they can do, so test the full result with a non-admin user.
Should we use a sharing rule for one temporary deal?
Usually, an automatic rule is better for a repeatable access pattern. For one Opportunity, an opportunity team or an appropriate individual share may fit better. Check the ownership and collaboration process before creating a rule that could include future deals unintentionally.
Why doesn’t a criteria-based rule match every expected record?
Check the field values on the missing records, including blanks, spelling differences, and values set by automation. Then confirm the rule’s conditions and the recipient’s group membership. Finally, allow recalculation to finish and test with a user who has the required object permission.
Conclusion
A revenue access request sounds simple until ownership, permissions, and existing sharing overlap. Start by naming the records and people involved, then choose the smallest repeatable rule that grants the needed access.
Representative-user testing closes the loop. It shows whether the team can do its work without exposing records beyond the intended scope.
