04.02.04 — Sharing Rules and Ownership Models

Lesson goal

This lesson explains how record visibility is calculated in Salesforce and why testing Profiles and Permission Sets alone is not enough.

After completing this lesson, you should be able to:

• understand how Salesforce determines who can see which records
• test Organization-Wide Defaults, Role Hierarchy, and Sharing Rules together
• validate ownership changes and their security impact
• design visibility tests that prevent unauthorized data exposure

This lesson completes the Security Testing section of Module 4.

The problem: access beyond the Profile

Profiles and Permission Sets define what a user can do.
They do not define which records a user can see.

Record visibility in Salesforce is determined by a layered model:

1. Organization-Wide Defaults (OWD) — baseline visibility for non-owners
2. Role Hierarchy — automatic vertical sharing
3. Sharing Rules — automatic horizontal sharing
4. Manual Sharing — ad-hoc, user-driven access

If QA validates only CRUD and FLS, sensitive data may still be visible to unauthorized users — a critical security and compliance risk.

Organization-Wide Defaults (OWD): the baseline

OWD defines the most restrictive access level for records a user does not own.

Every sharing test must start from OWD.

OWD setting	Meaning	QA test focus
Private	Only owner and managers can see the record	Verify non-owners cannot see the record
Public Read Only	All users can see, only owner can edit	Verify visibility without edit access
Public Read/Write	All users can see and edit	Verify unrestricted access

QA principle:
If OWD is not tested explicitly, all other sharing tests are unreliable.

Role Hierarchy: vertical access

The Role Hierarchy automatically grants managers access to records owned by their subordinates.

Test focus

• Preconditions:
• OWD set to Private
• User A reports to User B
• User A owns the record
• Action: User B accesses the record
• Expected result:
  User B can see the record despite Private OWD

This proves that vertical sharing overrides baseline restrictions.

Sharing Rules: horizontal access

Sharing Rules extend visibility across roles, teams, or criteria, independent of the Role Hierarchy.

Criteria-based sharing test

• Preconditions:
• Record field Region = EMEA
• Sharing Rule grants EMEA Sales Team Read/Write access
• Action: User in EMEA Sales Team accesses the record
• Expected result:
  Record is visible and editable

Negative criteria test

• Preconditions:
  Record field Region = APAC
• Expected result:
  EMEA Sales Team user must not see the record

Negative tests are mandatory to prove the rule does not over-share data.

Record ownership: the security pivot point

Ownership is the single strongest factor influencing visibility.

Any automation or manual action that changes OwnerId must be treated as high risk.

Ownership transfer test

• Preconditions:
• OWD set to Private
• User A owns the record
• Action: Owner is changed to User B
• Expected results:
• User B gains full access
• User A loses access unless covered by Role Hierarchy or Sharing Rule

If the original owner retains access unexpectedly, data isolation is broken.

Testing data isolation

The most important security validation is proving what a user cannot see.

Isolation test

• Action:
  As a restricted user, run:
• global search
• reports
• list views
• Expected result:
  Only records explicitly allowed by OWD, Role Hierarchy, or Sharing Rules are visible

If unrelated records appear, sharing configuration is incorrect.

Practical QA strategy

Always test from Private OWD

Whenever possible:

• test sharing logic starting from Private OWD
• explicitly verify which layer grants access

This exposes accidental over-sharing immediately.

Treat sharing failures as critical defects

Visibility defects are often:

• silent
• environment-dependent
• discovered late

QA should classify unexpected visibility as security-critical, even if no data was modified.

Summary

Record visibility in Salesforce is defined by ownership and sharing, not by Profiles or Permission Sets alone.

From a QA perspective:

• OWD defines the baseline
• Role Hierarchy grants vertical access
• Sharing Rules grant horizontal access
• ownership changes can instantly reshape security boundaries

By testing visibility layer by layer and focusing on denial paths, QA prevents unauthorized data exposure and ensures predictable, compliant access control.

What’s next

In the next section, we move from security to execution risk:
04.03.01 — Testing Declarative Automation: Flows and Entry Conditions