What Account Owners See

Module 3 of 6 in the chapter Overrides and Implicit Sharing: What You Get for Free, chapter 10 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When someone owns an account, how much of its contacts, opportunities and cases do they get, and who decides?

In module 2, the user who owned an account suddenly saw its opportunities and contacts. That was child implicit sharing. But I skipped the question that matters for design: how much did they get, view or edit? Salesforce’s answer: “The account owner’s role and settings configured in account sharing rules and manual shares determine the level of access to child records” (Implicit Sharing (opens in a new tab), Salesforce Help, checked 2026-11-07). This module is the first part of that sentence: the role.

Here’s something people miss. Just by creating a role, you’re already making sharing decisions.

When you add a role, Salesforce asks you to “Specify the role’s access to the child contacts, opportunities, and cases associated with accounts that users in the role own” (Create a User Role (opens in a new tab), Salesforce Help, checked 2026-11-07). Three settings, one for each kind of child:

Contact Access: “whether users can access other users’ contacts that are associated with accounts the users own.”
Opportunity Access: the same, for “other users’ opportunities.”
Case Access: the same, for “other users’ cases” (Role Fields (opens in a new tab), Salesforce Help, checked 2026-11-07).

Read the words “other users’” twice. The account owner already has their own opportunities. This setting is about the ones someone else owns, on an account that’s theirs. And Salesforce says it plainly: “This access applies regardless of who owns the contacts” (Create a User Role).

For each one you choose how much. Salesforce’s architects list the three: “The access levels that can be provided are View, Edit, and No access for each of the children objects when the role is created” (Platform Sharing Architecture (opens in a new tab), Salesforce Architects, checked 2026-11-07). And Help’s examples: users in a role “can edit all contacts associated with accounts that they own,” and “can view, but not edit, all opportunities associated with accounts that they own” (same page).

The API names say who the setting is for: ContactAccessForAccountOwner, OpportunityAccessForAccountOwner and CaseAccessForAccountOwner (UserRole (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-07). It’s set on the role, and it works for whoever in that role owns the account.

Different decisions along the branch

In class I build this live. Under a vice president, I add a manager role, and Salesforce asks right away: can users in this role view the opportunities on the accounts they own, or edit them? We’re deciding at this branch of the tree. I give the manager edit. Then I add a support role below the manager, and I get the same question, and the answer can be different. Support may only get view if they own the account.

That’s the power of it. You make different decisions along the branch of the tree, and on each role you decide contacts, opportunities and cases separately. A service manager’s role might give edit on cases and no access to other people’s opportunities, on the same accounts.

Click to enlarge

When you can’t set it

Two cases, and both make sense once you remember what implicit sharing is for.

The child is Public Read/Write. “If a child object’s organization-wide default is Public Read/Write, you can’t specify access, because you can’t use the role hierarchy to restrict access further than your organization-wide defaults” (Create a User Role). Everyone already edits every record. There’s nothing to add.
Contacts are Controlled by Parent. “If the organization-wide default for contacts is Controlled by Parent, you also can’t specify access” (same page). The contact follows its account. There’s nothing to decide.

And one floor: “you can’t set a user role with an opportunity access less than that specified in organization-wide defaults” (UserRole). If opportunities are Public Read Only, every role views them anyway; the role can only add edit.

So the setting matters most where you made the children Private. That’s exactly where module 2 said implicit sharing works.

Why “no access” is a real choice

Here’s a design you’ll meet. A rep owns an account. Someone else on another team owns a sensitive opportunity on that same account, maybe an acquisition, maybe a deal under an agreement that keeps it to a few people. Opportunities are Private.

If the rep’s role gives view on other users’ opportunities, the rep sees it, because they own the account. No rule, no team, no share. The role did it. If the business needs that opportunity kept from the account owner, the role’s Opportunity Access has to be no access, and the people who need it get it another way. Chapter 6, module 5 has the other tools for confidential records.

Four places child access is set

The role isn’t the only place that sets access to an account’s children. When an account is shared, the children’s level comes with it, and each way sets it on its own screen:

The role, for the account’s owner (this module).
An account sharing rule, for the people it shares the account with: you choose the account’s level and the contacts’, opportunities’ and cases’ levels on the rule, where Private is a choice (chapter 8, module 2).
An account team, member by member, within the limits chapter 9, module 2 covers.
A manual share of the account, where the children’s level “can’t be greater than the account owner’s default access from organization-wide defaults and the owner’s role,” in the words of Salesforce’s Manual Sharing Considerations (chapter 9, module 1).

Notice the last one. The owner’s role reaches past the owner. When the owner shares their account by hand, the role sets the ceiling for what they can give away.

Click to enlarge

What an architect decides here

For each role, the access its users get on other users’ contacts, opportunities and cases, on the accounts they own.
Which roles need no access on a child, because something on those accounts must stay with a few people.
Which children are Private, since that’s where the setting matters.
How the role’s settings line up with the child access on account rules, teams and manual shares, so the same account doesn’t open differently by accident.
Who reviews the role settings when the hierarchy changes, since every new role asks the question again.

Beyond the exam: what AI changes. An agent working for an account owner reads every child the owner’s role opens, including opportunities and cases other people own. If an agent summarizes “everything on my accounts,” that’s what it will summarize. So check the role’s child access for the users agents work for, and set no access where the business means it. Chapter 20 covers agents.

Explore

Create a User Role (opens in a new tab), Salesforce Help (checked 2026-11-07)
Role Fields (opens in a new tab), Salesforce Help (checked 2026-11-07)
UserRole (opens in a new tab), Object Reference, Winter ‘27 (checked 2026-11-07)
Implicit Sharing (opens in a new tab), Salesforce Help (checked 2026-11-07)
Platform Sharing Architecture (opens in a new tab), Salesforce Architects (checked 2026-11-07)