Salesforce Sharing Rules and Manual Sharing - Zero-Fluff, Hands-On Guide

Salesforce Sharing Rules & Manual Sharing: Zero-Fluff, Hands-On Guide

(For Admins Who Need to Secure Data Without Breaking Production)

1. What This Is & Why It Matters

Sharing rules in Salesforce are automated exceptions to your org-wide defaults (OWD). Think of OWD as the "default lock" on all records—sharing rules are the "master keys" you hand out to specific groups when the default lock is too restrictive.

Why this matters in production: - Security: If you don’t set up sharing rules correctly, users either see nothing (frustrating) or everything (a compliance nightmare). - Performance: Poorly designed sharing rules can slow down record access, especially in large orgs. - Audit & Compliance: Regulatory frameworks (GDPR, HIPAA, SOX) often require strict data access controls. Sharing rules are your first line of defense.

Real-world scenario: You’re the Salesforce Admin for a healthcare org. The Org-Wide Default (OWD) for Patient__c records is Private (only the record owner can see it). But: - Doctors need to see all patients in their department. - Billing teams need to see patients assigned to their region. - A single auditor needs temporary access to a patient’s record for a compliance review.

Without sharing rules: - Doctors can’t see their department’s patients-work stops. - Billing teams manually request access-delays and errors. - The auditor has to email IT for access-security risk.

With sharing rules: - Doctors automatically see their department’s patients. - Billing teams see patients in their region. - The auditor gets manual sharing access for 24 hours.

This guide will show you how to set this up without breaking existing security.

2. Core Concepts & Components

? Org-Wide Defaults (OWD)

• Definition: The baseline access level for all records in an object (e.g., Private, Public Read-Only, Public Read/Write).
• Production insight: If OWD is too permissive (e.g., Public Read/Write), sharing rules won’t help—you’ve already exposed everything. Always start with the most restrictive OWD possible.

? Sharing Rules

• Definition: Automated rules that grant additional access to records based on criteria (e.g., "Department = Cardiology") or record ownership (e.g., "All records owned by Team A").
• Types:
• Criteria-Based Sharing Rules: Share records matching specific field values (e.g., Region__c = "West").
• Owner-Based Sharing Rules: Share all records owned by a specific user/group (e.g., "All records owned by the Billing Team").
• Production insight: Sharing rules do not override OWD—they only extend access. If OWD is Private, sharing rules can grant Read or Read/Write, but not Full Access.

? Manual Sharing

• Definition: One-off record access granted by a record owner or admin (e.g., "Grant Bob access to this Account for 1 week").
• Production insight: Manual sharing is not scalable—use it for exceptions, not as a primary access method. Audit logs track manual shares, so document why access was granted.

? Role Hierarchy

• Definition: A hierarchy where users in higher roles inherit access to records owned by users below them.
• Production insight: If a user’s role changes, their access changes immediately. Always test role hierarchy changes in a sandbox first.

? Public Groups

• Definition: Custom groups of users (e.g., "West Region Team") used in sharing rules.
• Production insight: Public groups are not the same as queues (queues are for record ownership, groups are for sharing). Don’t mix them up!

? Sharing Sets (for Experience Cloud)

• Definition: A way to share records with external users (e.g., customers, partners) based on a common field (e.g., AccountId).
• Production insight: Sharing sets only work for external users—don’t try to use them for internal sharing.

? Implicit Sharing

• Definition: Automatic sharing between parent/child records (e.g., if you can see an Account, you can see its Contacts).
• Production insight: Implicit sharing cannot be disabled—it’s built into Salesforce. If you need to restrict child record access, adjust OWD or sharing rules.

? Sharing Recalculation

• Definition: The process Salesforce runs to update record access after changes (e.g., a new sharing rule, role change).
• Production insight: Large orgs may experience delays during recalculation. Schedule changes during low-traffic periods.

3. Step-by-Step Hands-On: Setting Up Sharing Rules

Prerequisites

You have System Administrator access. ? You’ve set Org-Wide Defaults (OWD) for the object (e.g., Patient__c = Private). ? You have a sandbox (recommended) or a dev org to test in.

Task: Grant Doctors Access to Patients in Their Department

Goal: Automatically share Patient__c records with doctors in the same department.

Step 1: Create a Public Group for Each Department

1. Go to Setup-Public Groups-New.
2. Label: Cardiology Doctors
3. Group Name: Cardiology_Doctors (auto-filled)
4. Search: Select Roles and Subordinates-Choose Doctor - Cardiology.
5. Click Save.

(Repeat for other departments, e.g., Neurology Doctors.)

Step 2: Create a Criteria-Based Sharing Rule

1. Go to Setup-Sharing Settings.
2. Under Manage sharing settings for:, select Patient__c.
3. Click New under Sharing Rules.
4. Rule Type: Based on criteria
5. Rule Name: Share with Cardiology Doctors
6. Criteria:
7. Field: Department__c
8. Operator: equals
9. Value: Cardiology
10. Share with: Public Groups-Cardiology Doctors
11. Access Level: Read Only (or Read/Write if needed)
12. Click Save.

Step 3: Verify the Rule Works

1. Log in as a test user in the Cardiology Doctors group.
2. Go to the Patients tab.
3. Verify they can see only patients where Department__c = "Cardiology".

Task: Grant Billing Teams Access to Patients in Their Region

Goal: Automatically share Patient__c records with billing teams based on region.

Step 1: Create a Public Group for Each Region

1. Go to Setup-Public Groups-New.
2. Label: West Region Billing
3. Group Name: West_Region_Billing
4. Search: Select Roles-Choose Billing - West.
5. Click Save.

Step 2: Create an Owner-Based Sharing Rule

1. Go to Setup-Sharing Settings-Patient__c-New.
2. Rule Type: Based on record owner
3. Rule Name: Share West Region Patients with Billing
4. Select which records to be shared:
5. Owned by: Roles-Doctor - West
6. Share with: Public Groups-West Region Billing
7. Access Level: Read Only
8. Click Save.

Step 3: Test the Rule

1. Log in as a West Region Doctor and create a test patient.
2. Log in as a West Region Billing user and verify they can see the patient.

Task: Manually Share a Patient Record with an Auditor

Goal: Temporarily grant an auditor access to a single patient record.

Step 1: Enable Manual Sharing (If Not Already On)

1. Go to Setup-Sharing Settings.
2. Under Manual User Record Sharing, click Edit.
3. Check Enable manual sharing of records.
4. Click Save.

Step 2: Manually Share the Record

1. Open the Patient__c record you want to share.
2. Click the Sharing button (if not visible, add it to the page layout).
3. Click Add.
4. Search for: The auditor’s name.
5. Access Level: Read Only
6. Reason: Compliance Audit - 24-hour access
7. Click Save.

Step 3: Verify & Revoke Access Later

1. Log in as the auditor and verify they can see the record.
2. After 24 hours, go back to the Sharing button and remove the auditor’s access.

4.-Production-Ready Best Practices

Security

Least Privilege: Start with Private OWD and only open access via sharing rules where necessary. ? Avoid "View All" Permissions: If a user needs access to a subset of records, use sharing rules instead of View All on their profile. ? Audit Manual Shares: Use Setup-Sharing Settings-View All Manual Shares to track who has access to what. ? Use Public Groups, Not Individual Users: Sharing rules should reference groups, not individual users, for scalability.

Performance

Limit Sharing Rules per Object: Salesforce recommends no more than 300 sharing rules per object. If you hit this limit, use Apex managed sharing instead. ? Avoid Complex Criteria: Sharing rules with formulas or cross-object references slow down recalculation. Keep criteria simple (e.g., Department__c = "Cardiology"). ? Schedule Recalculations: If you make bulk changes, schedule recalculations during off-peak hours (Setup-Sharing Settings-Recalculate).

Reliability & Maintainability

Test in Sandbox First: Sharing rules can unintentionally expose data. Always test in a sandbox before deploying to production. ? Document Why Rules Exist: Add a description to each sharing rule explaining its purpose (e.g., "Grants Cardiology Doctors access to their department’s patients"). ? Use Naming Conventions: - SR_[Object]_[Group]_[AccessLevel] (e.g., SR_Patient_Cardiology_ReadOnly). - PG_[GroupName] (e.g., PG_Cardiology_Doctors).

Observability

Monitor Sharing Recalculation: If users report missing records, check Setup-Sharing Settings-Recalculate for errors. ? Use Reports to Audit Access: - Report Type: Users with Access to Records - Filter by object and user to see who can access what. ? Set Up Alerts for Manual Shares: Use Process Builder or Flow to notify admins when a record is manually shared.

5. Common Mistakes & Traps

6.-Exam/Certification Focus (Salesforce Admin)

Typical Question Patterns

1. "Which sharing rule type should you use?"
2. Criteria-based: When sharing depends on field values (e.g., Region__c = "West").

3. Owner-based: When sharing depends on who owns the record (e.g., "All records owned by Team A").

4. "What’s the difference between a public group and a queue?"

5. Public Group: Used for sharing (e.g., "Grant access to this group").

6. Queue: Used for record ownership (e.g., "Assign records to this queue").

7. "Can sharing rules override OWD?"

8. No. Sharing rules extend access but cannot restrict it. If OWD is Public Read/Write, sharing rules won’t help.

9. "How do you grant temporary access to a single record?"

10. Manual sharing (not a sharing rule).

11. "What happens if a user’s role changes?"

12. Their access updates immediately based on the new role hierarchy.

Trap Distinctions

Common Scenario-Based Question

"A sales rep needs to see all Opportunities owned by their team, but OWD is Private. What’s the best solution?" ? Answer: Create an owner-based sharing rule to share records owned by the team with the rep. ? Wrong Answers: - "Change OWD to Public Read-Only" (too permissive). - "Use manual sharing" (not scalable). - "Grant the rep 'View All' permission" (overkill).

7.-Hands-On Challenge (With Solution)

Challenge:

You’re the admin for a real estate org. The OWD for Property__c is Private. Agents should only see properties in their region, but managers should see all properties.

Your task:
1. Create a public group for "East Region Agents."
2. Create a criteria-based sharing rule to share Property__c records where Region__c = "East" with the group.
3. Verify the rule works by logging in as an East Region Agent.

Solution:

1. Create the Public Group:
2. Setup-Public Groups-New.
3. Label: East Region Agents
4. Group Name: East_Region_Agents

5. Add all East Region Agent roles to the group.

6. Create the Sharing Rule:

7. Setup-Sharing Settings-Property__c-New.
8. Rule Type: Based on criteria
9. Rule Name: Share East Region Properties
10. Criteria: Region__c equals East
11. Share with: Public Groups-East Region Agents

12. Access Level: Read Only

13. Test:

14. Log in as an East Region Agent.
15. Verify they can see only properties where Region__c = "East".

Why it works: - The sharing rule extends access beyond the Private OWD for the specified group. - Managers (higher in the role hierarchy) automatically see all properties.

8.-Rapid-Reference Crib Sheet

9.-Where to Go Next

1. Salesforce Sharing & Visibility Documentation
2. Trailhead: Data Security (Free hands-on module)
3. Apex Managed Sharing (for advanced scenarios)
4. Salesforce Sharing & Visibility Designer Certification Guide (For advanced admins)

Final Thought

Sharing rules are your scalpel—they let you carve out precise access without swinging the Public Read/Write sledgehammer. Master them, and you’ll keep data secure while letting users do their jobs. Test in sandbox, document everything, and recalculate after changes. Now go build something secure! ?