Skip to content
SteveTechArcSteveTechArc Courses

The User Record Is a Record Too

Module 7 of 7 in the chapter Org-Wide Defaults, Ownership and the Role Hierarchy, chapter 6 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Every person in your org is a record on the User object. Who can see those records, and how do you hide people from each other when you need to?

When I walk a class through the Sharing Settings page, after the org-wide defaults there are some additional settings: standard report visibility, minimize the number of roles created, secure guest user record access, require permission to view record names in lookup fields. These are little setting switches at the org-wide default level, and most people scroll right past them. One row in the defaults table is easy to miss too: User.

A user is a record. It has a name, an email address, a phone number, a manager, a role. And like every other record, someone decides who can see it.

When people mustn’t see each other

Section titled “When people mustn’t see each other”

In most orgs, everyone seeing everyone is fine. Your colleagues are in the company directory anyway. But not always. Salesforce gives an example of an org with internal users and external users (Set the Org-Wide Sharing Defaults for User Records (opens in a new tab), Salesforce Help, checked 2026-11-07):

  • Employees can see everyone.
  • Sales agents can see employees, other agents, and their own customer user records only.
  • External customers can see other customers only if they are under the same agent or account.

Think of two partner companies that compete with each other, both working in your org. Should one see the other’s people, their names, their emails, how many of them there are? Usually not.

What seeing a user means

Section titled “What seeing a user means”

“Granting access to a user record makes the user’s detail page visible to others. It also makes the user visible in lookups, list views, search, and so on” (User Sharing Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07).

Read the second sentence again, because it cuts both ways. If you hide a user from someone, that person can’t find them in a lookup either. They can’t pick them as an owner, assign them a task, or add them to a team. So hiding users is a design decision, not just a privacy switch. Decide who needs to work with whom before you decide who can see whom.

Two defaults for user records

Section titled “Two defaults for user records”

For the User object there are only two choices, Private or Public Read Only (Organization-Wide Default Access Settings (opens in a new tab), Salesforce Help, checked 2026-11-07):

  • Public Read Only: “All users have read access on one another. You can see all users’ detail pages. You can also see all users in lookups, list views, ownership changes, user operations, and search.”
  • Private: “All users have read access to their own user record and those below them in the role hierarchy.”

When the feature is first turned on, the internal default is Public Read Only and the external default is Private, and “The default external access must be more restrictive or equal to the default internal access” (Set the Org-Wide Sharing Defaults for User Records).

And here’s the rule from module 2, in Salesforce’s own words, now for people: “The default must be set to Private if there is at least one user who shouldn’t see a record” (same page). Private if even one user mustn’t see another. Then open it up.

Who can see a user record Who can see a user record. Public Read Only, the internal default: everyone reads everyone, in detail pages, lookups, list views and search. Private, the external default: you read your own user record and the users below you in the role hierarchy. Opening Private up: the View All Users permission, user sharing rules by public group, role or territory, a manual share of one user record, and Manage External Users for external users. Footnote: Private if even one user mustn't see another; then open it up. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-13", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Public Read Only the internal default Everyone reads everyone Detail pages, lookups, list views, search Private the external default Your own user record Users below you in the role hierarchy Opening Private up the same kinds of tools View All Users permission User sharing rules: group, role, territory A manual share of one user Manage External Users Private if even one user mustn't see another. Then open it up. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Opening it back up

Section titled “Opening it back up”

Once user records are Private, you open them with the same kinds of tools you use for any record, with a few twists (User Sharing Considerations, checked 2026-11-07):

  • View All Users. A permission for people “who need Read access to all users, regardless of the sharing settings.” Anyone with Manage Users gets it automatically. That’s your admins, and whoever runs user setup.
  • User sharing rules. They “are based on membership to a public group, role, or territory. Each sharing rule shares members of a source group with those of the target group.” Build the groups first. And “Only users with roles can be included in sharing rules,” so high-volume site users, Chatter External and Chatter Free users can’t be shared this way, and neither can special users such as Automated Process and License Manager users.
  • Manual sharing of one user record. It “can grant read or edit access on an individual user, but only if the access is greater than the default access for the target user.” Apex managed sharing isn’t supported for users. The Sharing button on the user detail page is controlled by the Manual User Record Sharing checkbox on the Sharing Settings page, and Salesforce lists that page as available in Salesforce Classic (Control Manual Sharing for User Records (opens in a new tab), Salesforce Help, checked 2026-11-07).
  • Manage External Users. People with it see partner and customer user records “regardless of sharing rules or organization-wide default settings for User records” (User Sharing Considerations).

And the role hierarchy works here too: “Users inherit the same access as users below them in the role hierarchy” (same page). A manager sees the users their team can see.

Where names still show

Section titled “Where names still show”

Hiding users isn’t airtight, and Salesforce says where (User Sharing Considerations):

  • Chatter. “In a public Chatter group, everyone with access to the group can see all posts,” including the names of the people who post. And a past interaction can keep someone in your mention list.
  • Salesforce CRM Content. “A user who can create libraries can see users they don’t have access to when adding library members.”
  • Standard reports. That’s the next section.

So test it the way you’d test any record: log in as someone who shouldn’t see a person, and look in every place a name can appear.

Standard Report Visibility

Section titled “Standard Report Visibility”

This is the caveat I mention in the video. Standard report types can show data about users the viewer can’t see. The Standard Report Visibility checkbox decides whether those reports show at all. “When User Sharing is first enabled, all reports that contain data of users to whom a viewing user doesn’t have access are hidden” (Control Standard Report Visibility (opens in a new tab), Salesforce Help, checked 2026-11-07).

If user records are Private and you check the box, “a person viewing the report can see the names of users that are listed in the report. To see details such as username and email address, the viewer must have access to the users” (same page). If you clear it, users with View All Users still see those reports.

And the same page has a line every architect should know, about reports in general: “Standard Report types operate on the primary object’s sharing settings… Custom Report Types respect both primary and secondary object sharing.” Salesforce’s example: the standard Accounts and Assets report type respects only the account’s sharing; a custom report type on the same two objects respects both. If a report joins a sensitive child to its parent, build it on a custom report type. Chapter 12 covers reports.

Reports and the users in them Reports and the users in them. A standard report type follows the primary object's sharing only; Salesforce's example, Accounts and Assets, respects only the account's sharing. A custom report type respects the sharing of both objects. The Standard Report Visibility checkbox: checked, with user records Private, viewers see the names of users in the report but not their details; cleared, those reports are hidden, except from people with View All Users. Footnote: if a report joins a sensitive child to its parent, use a custom report type. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-OH-14", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Standard report type the primary object only Follows the primary object's sharing Accounts and Assets: account sharing only Custom report type both objects Respects primary and secondary sharing Accounts and Assets: both apply Standard Report Visibility one checkbox Checked: names show, not details Cleared: those reports hidden View All Users still sees them If a report joins a sensitive child to its parent, use a custom report type. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

External users

Section titled “External users”

Most of the time, user visibility matters most for people outside the company: partners, customers, site members. Which site users can see each other, and which of their personal fields other external users can see, are settings of their own. Chapter 14 covers them with external users.

What an architect decides here

Section titled “What an architect decides here”
  • Whether any user mustn’t see another, and so whether the internal and external defaults for User are Private.
  • Who needs View All Users, knowing everyone with Manage Users already has it.
  • Which public groups, roles or territories user sharing rules will use, and who can’t be in them (users with no role, high-volume site users, Chatter External and Chatter Free).
  • Whether users may share their own user record, set with the Manual User Record Sharing checkbox.
  • Whether Standard Report Visibility is on, and which reports must be built on custom report types.
  • How you’ll test it: as a user who mustn’t see someone, in lookups, search, Chatter, files and reports.

Beyond the exam: what AI changes. People ask agents about people: who owns this account, who’s my contact, email the manager. An agent finds the users its user can see. With Public Read Only, that’s every employee’s name, title, email and phone, ready to be put in an answer. If a user mustn’t see another user, the agent working for them mustn’t either, so set the defaults first and test the agent in the same places you test the person. Chapter 20 covers agents.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.