Record Access in Salesforce

Record Access in Salesforce

Welcome to Post 11 of our Salesforce series! In the previous post, we covered Profiles and Permission Sets — the tools that control what users can do in Salesforce (which objects they can access, which fields they can see, and which features they can use). But controlling what users can do is only half the security picture. The other half is controlling which records users can see and edit.

That’s where record access comes in. Even if a user has full CRUD permissions on the Account object through their profile, they might only be allowed to see accounts owned by their team. Record access is what makes that possible.

This post is one of the longest and most important in the entire series. Record access is a topic that trips up even experienced admins, so we’re going to break it down piece by piece.

What Is Record Access?

Record access (also called record-level security or sharing) determines which specific records a user can see and what they can do with those records (view, edit, transfer, delete).

Think of it this way:

Object-level and field-level security set the ceiling — the maximum a user can ever do. Record-level security then narrows it down further by controlling which records the user can see.

Key principle: Record access can only open up access from the baseline. It cannot restrict access below the Organization-Wide Default. This is a critical concept we’ll revisit throughout the post.

The Record Access Pyramid

Salesforce uses a layered model for record access, often visualized as a pyramid. Each layer builds on the one below it, progressively opening up access to more records.

            ┌─────────────┐
            │   Manual     │  ← Most targeted
            │   Sharing    │
            ├─────────────┤
            │  Sharing     │
            │  Rules       │
            ├─────────────┤
            │  Role        │
            │  Hierarchy   │
            ├─────────────┤
            │  Organization│  ← Most restrictive
            │  Wide Default│
            └─────────────┘

Here’s the full picture from bottom to top:

1. Organization-Wide Defaults (OWD) — The baseline. Sets the most restrictive level of access for each object.
2. Role Hierarchy — Users higher in the hierarchy inherit access to records owned by users below them.
3. Sharing Rules — Automatically share records between groups of users based on ownership or criteria.
4. Manual Sharing — Record owners (and admins) can manually share individual records with specific users or groups.
5. Other mechanisms — Teams, territory management, Apex sharing, sharing sets, etc.

Each layer can only add access — never take it away. If OWD gives everyone Read access, no sharing rule can reduce that to Private.

Organization-Wide Defaults (OWD)

OWD is the foundation of the entire record access model. It defines the baseline level of access that all users have to each other’s records. You then use the other tools (roles, sharing rules, etc.) to open up access from there.

OWD Settings

How to Set OWD

1. Go to Setup → Sharing Settings.
2. Click Edit in the Organization-Wide Defaults section.
3. For each object, select the desired default access level from the dropdown.
4. Check or uncheck Grant Access Using Hierarchies (more on this below).
5. Click Save.

After saving, Salesforce recalculates sharing for all records. On orgs with large data volumes, this can take time.

Choosing the Right OWD

The rule of thumb is: set OWD to the most restrictive level that your most restricted user needs, then open up access from there.

Ask yourself: “Should every single user in my org be able to see every record of this object?” If the answer is no, start with Private and open up access using roles and sharing rules.

Here are common scenarios:

Grant Access Using Hierarchies

When you configure OWD, you’ll see a checkbox called Grant Access Using Hierarchies for each object. When enabled (which is the default), users higher in the role hierarchy automatically get access to records owned by users below them.

For standard objects, this checkbox is always enabled and cannot be turned off. For custom objects, you can disable it — which is useful in scenarios like HR where a manager shouldn’t automatically see all HR case records owned by their reports.

What Is Implicit Sharing?

Before we get into roles and sharing rules, it’s important to understand implicit sharing — access that Salesforce grants automatically behind the scenes, without any admin configuration.

Implicit sharing exists because certain objects are closely related, and it wouldn’t make sense to see one without the other.

Types of Implicit Sharing

Parent-to-child (downward): If a user has access to a parent account, they get Read Only access to the child records associated with that account — including opportunities, cases, and contacts related to that account.

Child-to-parent (upward): If a user has access to a child record (like an opportunity or case), they get Read Only access to the parent account. This ensures that if a sales rep can see an opportunity, they can also see which account it belongs to.

Portal implicit sharing: Portal users get access to records based on their portal account association.

Here’s a summary:

Implicit sharing is automatic and cannot be turned off. It’s a common source of confusion when users can see records that admins didn’t explicitly share. If a user can mysteriously see an account they don’t own, check whether they have access to a child opportunity or case — implicit sharing might be the cause.

Roles and the Role Hierarchy

What Are Roles?

Roles in Salesforce define a hierarchy that controls record visibility. Users higher in the hierarchy can see records owned by users below them (when Grant Access Using Hierarchies is enabled).

Important distinction: Roles are NOT the same as job titles or profiles.

A VP of Sales and a Sales Rep might have the same profile (same object and field permissions), but different roles — so the VP can see the rep’s records but not vice versa.

How the Role Hierarchy Works

The role hierarchy is like an org chart for data visibility:

                    CEO
                   /   \
           VP Sales     VP Support
           /    \           |
    Sales Mgr  Sales Mgr  Support Mgr
       |          |           |
    Sales Rep  Sales Rep  Support Agent

In this hierarchy:

• The CEO can see all records owned by every user below them.
• VP Sales can see all records owned by Sales Managers and Sales Reps, but NOT records owned by VP Support or Support Agents.
• Sales Reps can only see their own records (plus anything shared through other mechanisms).

How to Create Roles

1. Go to Setup → Roles.
2. If this is your first time, you’ll see a prompt to set up the hierarchy. Select a tree view (I recommend the tree view for clarity).
3. Click Add Role beneath the role you want the new role to report to.
4. Fill in:
   • Label: The display name (e.g., “Sales Manager - West”)
   • Role Name: The API name (auto-populated)
   • This role reports to: The parent role in the hierarchy
   • Role Name as displayed on reports: How it appears in reports
5. Configure Contact Access, Opportunity Access, and Case Access for the role. These determine the default sharing level for related records when you own the parent account.
6. Click Save.

How to Assign Roles to Users

1. Go to Setup → Users.
2. Click Edit next to the user.
3. In the Role field, select the appropriate role from the lookup.
4. Click Save.

Alternatively, from the Role Hierarchy page:

1. Click the role name.
2. Click Assign Users to Role.
3. Move users from the Available Users list to the Selected Users list.
4. Click Save.

Role Hierarchy Best Practices

• Model the hierarchy around data visibility, not org charts. A contractor might report to a VP organizationally but should be at the bottom of the role hierarchy for security purposes.
• Keep it simple. Deep hierarchies are hard to maintain and can cause performance issues with sharing recalculations.
• Every user should have a role. Users without roles can cause issues with reporting, forecasting, and sharing. Salesforce displays a warning for users without roles.
• Don’t create one role per person. Roles should represent functional groups, not individuals.

Public Groups

What Are Public Groups?

Public groups are collections of users, roles, other groups, or any combination of these. They simplify sharing by letting you share records with a group instead of individual users.

Think of public groups as distribution lists for record access. Instead of creating a sharing rule that says “share with User A, User B, and User C,” you create a group containing those users and share with the group.

Types of Members in a Public Group

A public group can contain:

How to Create a Public Group

1. Go to Setup → Public Groups.
2. Click New.
3. Fill in:
   • Label: A descriptive name (e.g., “West Region Sales Team”)
   • Group Name: The API name (auto-populated)
   • Grant Access Using Hierarchies: If checked, users higher in the role hierarchy than group members also get the shared access.
4. In the Search dropdown, select the type of member to add (Users, Roles, etc.).
5. Select members from the Available Members list and click Add to move them to Selected Members.
6. Click Save.

When to Use Public Groups

• When you need to share records with a specific cross-functional team that doesn’t align with the role hierarchy.
• When the same set of users needs to be referenced in multiple sharing rules.
• When you want to simplify sharing rule maintenance — update the group membership instead of rewriting sharing rules.
• When assigning default owners for list views or report folders.

Queues

What Are Queues?

Queues are holding areas for records that need to be worked by a group of users. Records in a queue don’t have a specific owner — instead, they’re owned by the queue and visible to all queue members. Any queue member can claim a record from the queue by taking ownership of it.

Queues are available for the following objects:

• Cases
• Leads
• Orders
• Custom Objects
• Service Contracts
• Knowledge articles (versions)

How to Create a Queue

1. Go to Setup → Queues.
2. Click New.
3. Fill in:
   • Label: A descriptive name (e.g., “West Region Lead Queue”)
   • Queue Email: An optional email address for notifications when records enter the queue.
   • Send Email to Members: Check this if queue members should be notified when new records are added.
4. Under Supported Objects, add the objects this queue should support (e.g., Lead, Case).
5. Under Queue Members, add users, roles, public groups, or any other member type.
6. Click Save.

How Queues Work in Practice

1. A new lead comes in through a web form.
2. A lead assignment rule routes the lead to the “West Region Lead Queue.”
3. All members of the queue can see the lead in a list view called “My Queues.”
4. A sales rep reviews the lead and clicks Change Owner → assigns it to themselves (or uses Accept on the lead).
5. The lead now belongs to the rep, and the queue no longer owns it.

Queues are essential for fair distribution of workload and ensuring no record falls through the cracks.

Difference Between Queues and Public Groups

This is one of the most commonly confused topics in Salesforce administration. Let’s clear it up:

When to use which:

• Use a public group when you need to share records that already have individual owners.
• Use a queue when you need a holding area for unassigned records that team members can claim.

You can use both together: create a public group for sharing, and a queue for record assignment, with the same members in both.

Sharing Rules

What Are Sharing Rules?

Sharing rules are automated rules that extend record access beyond what OWD provides. They let you share records owned by one group of users with another group of users.

Sharing rules are the primary tool for opening up access when OWD is set to Private or Public Read Only. They only work in the “open up” direction — you cannot use sharing rules to restrict access below the OWD level.

Types of Sharing Rules

Criteria-based sharing rules are more flexible but have some limitations — they don’t support formula fields or some field types as criteria.

How to Create a Sharing Rule

1. Go to Setup → Sharing Settings.
2. Scroll down to the object you want to create a rule for (e.g., Opportunity Sharing Rules).
3. Click New in the sharing rules section for that object.
4. Fill in:
   • Label: A descriptive name (e.g., “Share Escalated Cases with VP Support”)
   • Rule Type: Select Based on record owner or Based on criteria.
5. For owner-based rules:
   • Select who owns the records to share (a role, role and subordinates, public group, or queue).
6. For criteria-based rules:
   • Define the field criteria (e.g., Status equals Escalated).
7. Share with: Select the target — a role, role and subordinates, public group, or queue.
8. Access Level: Choose Read Only or Read/Write.
9. Click Save.

Sharing Rule Examples

Example 1: Owner-based

• Records owned by: Role = “Sales Rep - West”
• Share with: Role and Subordinates = “VP Sales”
• Access Level: Read/Write

This shares all records owned by West Sales Reps with the VP Sales and everyone below VP Sales in the hierarchy.

Example 2: Criteria-based

• Criteria: Case.Priority equals High AND Case.Status equals Escalated
• Share with: Public Group = “Escalation Team”
• Access Level: Read/Write

This shares all high-priority escalated cases with the Escalation Team group, regardless of who owns them.

Sharing Rule Considerations

• Sharing rules run asynchronously. After creating or modifying a rule, it may take some time for access changes to take effect.
• There are limits on the number of sharing rules per object (varies by edition; typically 300 owner-based and 50 criteria-based per object).
• Criteria-based sharing rules recalculate when a record is created or updated. If a case’s status changes from Escalated to Closed, the sharing rule may no longer apply.
• Sharing rules apply to existing and future records that match the criteria.

Sharing Sets

What Are Sharing Sets?

Sharing sets are designed for Experience Cloud (community/portal) users. They grant external users access to records associated with their account or contact.

The problem sharing sets solve: External users have very limited access by default. You can’t use the role hierarchy or standard sharing rules effectively for portal users because they sit outside your internal org structure.

How Sharing Sets Work

A sharing set works by matching a field on the user record to a field on the target record. For example:

• The portal user’s Account field matches the Account field on Case.
• So the portal user can see all cases related to their account.

How to Create a Sharing Set

1. Go to Setup → Digital Experiences → Settings (or search for “Sharing Sets” in Setup).
2. Under Sharing Sets, click New.
3. Fill in:
   • Label: A descriptive name (e.g., “Customer Portal Case Access”)
4. Under Profiles, select the community/portal user profiles this sharing set applies to.
5. Under Access Mapping, click New:
   • Target Object: The object you want to grant access to (e.g., Case).
   • User field: The field on the User record used for matching (e.g., Account).
   • Target field: The field on the target object used for matching (e.g., Account).
   • Access Level: Read Only or Read/Write.
6. Click Save.

When to Use Sharing Sets

• When you have Experience Cloud users who need to see records related to their account or contact.
• When the standard portal sharing model doesn’t give you enough control.
• When you need external users to see records owned by internal users (e.g., a customer viewing their support cases).

Sharing Groups

What Are Sharing Groups?

Sharing groups (also called share groups) are used in Experience Cloud to define which internal users’ data is shared with external users. They work alongside sharing sets to control the flow of data from your internal org to your portal.

Types of Sharing Groups

There are two types:

How to Create a Sharing Group

1. Go to Setup → Digital Experiences → Settings.
2. Scroll down to the Sharing Groups section.
3. For each sharing group:
   • Click Edit next to the group.
   • Add the internal users, roles, or groups whose data should be visible to portal users.
   • Click Save.

When to Use Sharing Groups

• When you need to control exactly which internal users’ records are visible through your community/portal.
• When you want to ensure that only records owned by specific internal teams are visible to partner or customer portal users.
• In combination with sharing sets for fine-grained control over portal data visibility.

The Many Other Ways to Grant Users Record Access

Beyond the main tools we’ve covered, Salesforce offers several additional mechanisms for granting record access:

Manual Sharing

Record owners and administrators can manually share individual records with specific users, roles, or groups.

How to manually share a record:

1. Open the record you want to share.
2. Click the Sharing button (on Classic) or go to Sharing in the record’s dropdown menu (Lightning).
3. Click Add.
4. Search for the user, role, or group.
5. Select the Access Level (Read Only or Read/Write).
6. Set a Reason (optional, used for tracking).
7. Click Save.

Manual sharing is deleted when the record owner changes.

Account Teams

Account teams let the account owner add other users to work on the account, each with a specific access level.

How to add a team member:

1. Open the Account record.
2. In the Account Team related list, click Add Team Members.
3. Select the user, their role on the team, and the access levels.
4. Click Save.

Opportunity Teams

Similar to account teams but for opportunities. Each team member gets a role and a specific access level on the opportunity.

Territory Management

Enterprise Territory Management assigns accounts to territories, and users assigned to those territories get access to the accounts. This is an advanced feature used by organizations with complex sales territory structures.

Apex Managed Sharing (Programmatic Sharing)

Developers can write Apex code to programmatically create sharing records in the __Share table. This is the most flexible option and is used when no declarative tool can meet the requirement.

// Example: Share an account record with a specific user
AccountShare accountShare = new AccountShare();
accountShare.AccountId = '001XXXXXXXXXXXX';
accountShare.UserOrGroupId = '005XXXXXXXXXXXX';
accountShare.AccountAccessLevel = 'Edit';
accountShare.OpportunityAccessLevel = 'Read';
accountShare.RowCause = Schema.AccountShare.RowCause.Manual;
insert accountShare;

Key points about Apex sharing:

• Every object with OWD set to Private or Public Read Only has a corresponding __Share object (e.g., AccountShare, CaseShare, MyCustomObject__Share).
• You can define custom sharing reasons (Apex sharing reasons) for custom objects to make sharing records more durable — they survive ownership changes.
• Apex-managed sharing is not deleted when the record owner changes (unlike manual sharing).

Guest User Sharing Rules

For unauthenticated (guest) users on Experience Cloud sites, you can create special sharing rules that control which records are visible to users who haven’t logged in. These are configured separately under the guest user profile’s sharing settings.

Restriction Rules

While everything we’ve covered so far opens up access, restriction rules do the opposite — they restrict access even when a user would otherwise have it.

Restriction rules were introduced to address a common pain point: with the standard sharing model, you can only open up access from the OWD baseline. But what if you need most users to see all records, yet hide a specific subset from certain users?

How Restriction Rules Work

A restriction rule filters out records from a user’s view based on criteria you define. If a record matches the restriction criteria for a user, that user cannot see or access it — even if other sharing mechanisms would normally grant access.

Available for: Custom objects, Contracts, Events, Tasks, and several standard objects.

How to Create a Restriction Rule

1. Go to Setup → Restriction Rules (or search for it in Quick Find).
2. Click New Rule.
3. Select the Object.
4. Fill in:
   • Rule Name: A descriptive name.
   • Active: Check to enable the rule.
5. Define the User Criteria: Which users does this rule apply to? For example, Profile.Name equals "Limited Sales User".
6. Define the Record Criteria: Which records should be hidden? For example, Region equals "Confidential".
7. Click Save.

Restriction Rule Example

Scenario: All sales users can see all accounts (OWD = Public Read Only), but interns should not see accounts in the “Strategic” tier.

• User Criteria: Profile.Name equals "Sales Intern"
• Record Criteria: Account_Tier__c equals "Strategic"

Now, when a Sales Intern runs a report or searches for accounts, Strategic tier accounts simply won’t appear. They’re effectively invisible.

Restriction Rule Considerations

• Restriction rules are enforced across the platform — SOQL queries, reports, list views, searches, and related lists all respect them.
• They don’t appear in the sharing model or sharing debug tools, which can make troubleshooting confusing. Always check restriction rules if a user reports missing records.
• Restriction rules take priority over sharing rules. Even if a sharing rule grants access, a restriction rule can override it.
• There are limits on the number of restriction rules per object (typically 2 active rules per object).

How to View What Users Have Access to a Record and Why

Debugging record access issues is one of the most common admin tasks. Salesforce provides several tools to help.

Sharing Button on Records

1. Navigate to the record in question.
2. In Lightning, click the dropdown arrow on the record page and select Sharing.
3. You’ll see a list of users who have access and their access level.

Sharing Hierarchy (Sharing Debug)

For a more detailed view:

1. On the Sharing detail page for a record, look for the Expand List button.
2. This shows not just direct sharing but also access inherited through the role hierarchy, sharing rules, and teams.

The “Why” Column

When viewing sharing on a record, the Reason column tells you why each user has access:

User Access Check (Lightning)

In Lightning Experience, you can check a specific user’s access:

1. Open the record.
2. Click Sharing from the dropdown.
3. Click Check Access (or User Access Check).
4. Search for the user.
5. Salesforce shows the user’s effective access level and the reason for that access.

Sharing Debug Tool (Classic)

In Classic, there’s a similar tool:

1. Open the record and click Sharing.
2. Click Why does this user have access?
3. Select the user.
4. View the breakdown of access sources.

Debugging Tips

1. Start with the obvious: Does the user own the record? Is OWD set to Public Read/Write?
2. Check the role hierarchy: Is the user above the record owner in the hierarchy?
3. Look at sharing rules: Are there owner-based or criteria-based rules that match?
4. Check teams: Is the user on an account or opportunity team?
5. Check implicit sharing: Does the user have access to a child or parent record?
6. Check restriction rules: If a user can’t see a record, restriction rules might be filtering it out.
7. Check manual sharing: Someone may have manually shared the record.
8. Check Apex sharing: Developers may have created sharing records programmatically.

Section Notes

Here are the key takeaways and common pitfalls to keep in mind:

Key Takeaways

1. Record access can only open up from the OWD baseline. The OWD is the floor. Sharing rules, roles, and other mechanisms add access on top of it. The one exception is restriction rules, which can filter records from a user’s view.

2. Set OWD as restrictive as possible. Start with Private and open up access only where needed. It’s much easier to grant access than to take it away.

3. Roles are for data visibility, not job titles. Design your role hierarchy around who needs to see whose data, not around your org chart.

4. Every user should have a role. Users without roles cause problems with reporting, forecasting, and sharing.

5. Public groups simplify sharing rule management. Instead of creating sharing rules for individual users, put them in groups and share with the group.

6. Queues are for unassigned work. Use queues when records need to be claimed by team members, not just shared.

7. Implicit sharing is automatic. Understanding parent-child implicit sharing helps explain “mysterious” access.

8. Restriction rules override everything. They’re a powerful tool but can be confusing to debug because they don’t appear in standard sharing tools.

Common Pitfalls

• Forgetting to assign roles: Users without roles don’t participate in role-based sharing, and their records may be invisible to managers.
• Over-relying on manual sharing: Manual sharing is deleted when ownership changes. Use sharing rules for durable access.
• Ignoring implicit sharing: When troubleshooting access issues, always consider whether child-to-parent or parent-to-child implicit sharing is in play.
• Too many sharing rules: Large numbers of sharing rules can slow down sharing recalculations. Consolidate where possible using public groups.
• Confusing profiles and roles: Remember — profiles control what you can do, roles control which records you can see.

Sharing Performance Tips

• Keep your role hierarchy as shallow as possible.
• Use public groups to consolidate sharing rules.
• Avoid criteria-based sharing rules on frequently updated fields (they trigger recalculations).
• Monitor the Sharing Recalculation queue in Setup if you’re making bulk changes.
• For large orgs, consider deferred sharing calculations during data migrations.

PROJECT: Setup Record Access for Two User Personas

Let’s put everything together with a hands-on project. We’ll configure record access for a fictional company with two distinct user personas.

Scenario

AcmeTech has two sales teams:

• West Region Team — Handles accounts in western states.
• East Region Team — Handles accounts in eastern states.

Requirements:

1. Sales reps should only see their own opportunities (Private OWD).
2. Sales managers should see all opportunities owned by reps in their region.
3. Both teams should have read access to each other’s accounts (for context when collaborating).
4. Escalated cases should be visible to a cross-functional escalation team.
5. A partner portal user should be able to see cases associated with their account.

Step 1: Set Organization-Wide Defaults

1. Go to Setup → Sharing Settings → Edit.
2. Set the following OWD values:

3. Ensure Grant Access Using Hierarchies is checked for all objects.
4. Click Save and wait for the sharing recalculation to complete.

Why these settings?

• Accounts are Public Read Only because both teams need to see all accounts (requirement #3), but reps should only edit their own.
• Opportunities are Private because reps should only see their own (requirement #1).
• Cases are Private so we can selectively share escalated cases (requirement #4).
• Contacts are Controlled by Parent because contact visibility should follow account visibility.

Step 2: Create the Role Hierarchy

1. Go to Setup → Roles.
2. Create the following hierarchy:

                CEO
               /   \
      VP Sales West   VP Sales East
          |               |
    Sales Mgr West   Sales Mgr East
      /       \         /       \
  Rep West 1  Rep West 2  Rep East 1  Rep East 2

Steps to create each role:

1. Click Add Role under the parent role.
2. Enter the Label (e.g., “Sales Manager - West”).
3. Set Contact, Opportunity, and Case access as needed.
4. Save.

Step 3: Assign Users to Roles

1. Go to Setup → Users.
2. Edit each user and assign them to the appropriate role:

Step 4: Create Public Groups

We’ll create two groups for use in sharing rules.

Group 1: “All West Region Sales”

1. Go to Setup → Public Groups → New.
2. Label: “All West Region Sales”
3. Add members: Role and Subordinates = “VP Sales - West”
4. Save.

Group 2: “Escalation Team”

1. Create another public group.
2. Label: “Escalation Team”
3. Add members: Individual users from both regions who handle escalations (e.g., Bob Smith, Frank Brown, and any dedicated escalation specialists).
4. Save.

Step 5: Create a Queue for Cases

1. Go to Setup → Queues → New.
2. Label: “Escalation Queue”
3. Supported Object: Case
4. Queue Members: Add the “Escalation Team” public group.
5. Save.

Now escalated cases can be assigned to this queue, and all escalation team members can see and claim them.

Step 6: Create Sharing Rules

Sharing Rule 1: Share West Opportunities with East (Read Only)

1. Go to Setup → Sharing Settings.
2. Under Opportunity Sharing Rules, click New.
3. Label: “West Opps Visible to East Managers”
4. Rule Type: Based on record owner.
5. Records owned by: Role and Subordinates = “VP Sales - West”
6. Share with: Role = “VP Sales - East”
7. Access Level: Read Only
8. Save.

Sharing Rule 2: Share East Opportunities with West (Read Only)

Repeat the process in reverse:

• Records owned by: Role and Subordinates = “VP Sales - East”
• Share with: Role = “VP Sales - West”
• Access Level: Read Only

This satisfies a common executive need — each VP can see the other region’s pipeline without being in the same branch of the hierarchy.

Sharing Rule 3: Share Escalated Cases with Escalation Team

1. Under Case Sharing Rules, click New.
2. Label: “Escalated Cases to Escalation Team”
3. Rule Type: Based on criteria.
4. Criteria: Status equals Escalated
5. Share with: Public Group = “Escalation Team”
6. Access Level: Read/Write
7. Save.

Now any case with Status = Escalated is automatically visible and editable by the Escalation Team, regardless of who owns it.

Step 7: Create a Sharing Set for Partner Portal Users

1. Go to Setup → Digital Experiences → Settings.
2. Under Sharing Sets, click New.
3. Label: “Partner Case Access”
4. Profiles: Select the partner community user profile.
5. Access Mapping:
   • Target Object: Case
   • User Field: Account
   • Target Field: Account
   • Access Level: Read Only
6. Save.

Now partner portal users can see all cases associated with their account.

Step 8: Verify the Configuration

Test with each persona to confirm access is working correctly:

As Carol Davis (Sales Rep - West 1):

• Can see all accounts (OWD = Public Read Only) ✓
• Can only see her own opportunities ✓
• Cannot see opportunities owned by other reps ✓
• Cannot see non-escalated cases owned by other users ✓

As Bob Smith (Sales Manager - West):

• Can see all accounts ✓
• Can see opportunities owned by Carol and Dave (role hierarchy) ✓
• Cannot see East region opportunities (unless VP-level sharing rule gives access) ✓
• Can see escalated cases (Escalation Team member) ✓

As Alice Johnson (VP Sales - West):

• Can see all accounts ✓
• Can see all West region opportunities (role hierarchy) ✓
• Can see East region opportunities (sharing rule) ✓

As a Partner Portal User:

• Can see cases related to their account (sharing set) ✓
• Cannot see cases for other accounts ✓

Bonus: Create a Restriction Rule

Let’s say AcmeTech has some accounts flagged as “Confidential” that interns should never see, even though OWD is Public Read Only.

1. Go to Setup → Restriction Rules → New Rule.
2. Object: Account.
3. Rule Name: “Hide Confidential Accounts from Interns”
4. Active: Checked.
5. User Criteria: Profile.Name equals "Intern"
6. Record Criteria: Account_Classification__c equals "Confidential"
7. Save.

Now, interns cannot see Confidential accounts in any view, search, report, or SOQL query.

Project Summary

In this project, we configured a complete record access model using:

This covers the most common record access patterns you’ll encounter as a Salesforce administrator. The key is to always start with the most restrictive OWD and open up access methodically using the tools in the record access pyramid.

Coming up next, we’ll dive into another critical Salesforce administration topic. See you in the next post!