List Views, Reports, Search and Files

Module 4 of 6 in the chapter Object and Field Security: What Users Can Touch, chapter 4 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Once a user can open a record, where else can its data show up, and what does field-level security not cover?

Module 3 ended with a list view showing every value that was hidden on the page. I call that data bleed: once somebody has access, the data bleeds out through every other way into the org. This module walks through those ways, and the two places where even field-level security doesn’t help.

Where a granted field shows up

If a user has Read on a field, they can see its value almost anywhere. Salesforce’s own list, from module 2: field-level security controls the field in “reports, search results, list views, related lists, email, and mail merge templates, custom links,” and “API access” (Ways to Control User Access to Fields (opens in a new tab), Salesforce Help, checked 2026-11-01). Turn that around, and it’s the list of places a field shows up once it’s granted.

• List views. Anyone can take a list view and add the field. You can’t stop them.
• Reports and dashboards. A report on the object can show the field for every record the user can see.
• Global search. Search reaches past every page layout and list view. In my experience, global search is a killer: it’s the first place someone stumbles on something they shouldn’t see.
• The API, and everything built on it: integrations, data loads, and the tools people use to export data.

That’s why module 2 is the real control. Take the field away with field-level security, and it’s gone from all of these at once. Hide it on the page, and it’s gone from the page only.

The name you can’t hide

Now the first gap. Every record has a name, and the name goes everywhere. For a custom object, the Record Name is “The name used in page layouts, list views, related lists, and search results” (Fields Required for Creating Custom Objects (opens in a new tab), Salesforce Help, checked 2026-11-01). It’s how the record is shown wherever the record is shown.

Chapter 1 had the CEO and the complaint. Here’s the same kind of record from another angle. A student once asked me how to keep an HR team’s complaint details private while still letting others see the overall numbers. Page layouts won’t work, I said, and field-level security on the detail fields helps. But think about the complaint record’s name. If someone types the subject of the complaint into the name, about a named manager, then every person who can see the record in a list, a report or a search result reads it. Field-level security on the other fields doesn’t help, because the words are in the name.

Two habits follow.

• Keep sensitive words out of names. For a custom object holding sensitive records, consider an auto-numbered record name. The data type for the record name is “text or auto-number,” and auto-numbered names “are always a read-only field.” Salesforce adds one caution: with Auto Number, “there could be issues when inserting a high volume of records, for example, via the API” (same page).
• Know the lookup setting. If you enable Require permission to view record names in lookup fields, users “must have Read access to these records or the View All Lookup Record Names permission” to see the names in lookup and system fields (What Determines Field Access? (opens in a new tab), Salesforce Help, checked 2026-11-01). Without it, a name can show up in a lookup on a record the user can see, even when the record it points to isn’t shared with them.

The files on the record

The second gap is bigger. Field-level security protects fields. It doesn’t protect the files attached to the record.

Here’s what happens. You’ve hidden the sensitive fields with field-level security, but someone attaches a document to the record: a review, a medical note, a scanned letter. With Set by Record turned on for files attached to records, “Users with read-only record access get Viewer access to attached files,” and users with read/write access get Collaborator access. And “Viewers can view, download, and share files” (Set File Sharing to Inherit Record Permissions (opens in a new tab), Salesforce Help, checked 2026-11-01). So a file follows the record, not the fields. Anyone who can see the record can open what’s attached to it, download it, and share it on.

There’s one control on the file itself. File Privacy on Records has two options: “Visible to Anyone With Record Access,” or “Private on Records,” which “lets only the file owner see the file under Files on the record’s Related tab.” Only admins and file owners can change it. And know its limit: “On private files, file metadata isn’t also private,” so a user without access can still see, for example, who’s following the file (Make a File Private on a Record (opens in a new tab), Salesforce Help, checked 2026-11-01).

That’s a setting each owner has to remember, file by file. It’s not a design you can rely on for confidential data.

Click to enlarge

The day I found the reviews

Chapter 1, module 3 told this story. Here’s why it belongs in this module. While we were building our own system at a consultancy, we had one employee object for both time tracking and HR. During the build, I typed into global search and found myself looking at people’s reviews. They’d been attached to employee records that everyone could see, and an attached file follows its record: if you could see the record, you could see what was attached to it.

We split the object. HR got its own employee object, with its own access. Time tracking moved to a second object, a resource, and that’s what people tracked their time against. Nobody needed to see an HR employee record to log their hours.

Click to enlarge

When confidential data needs its own object

That story is the general rule. When one record serves two audiences, and one of them must never see part of it, field-level security protects the fields, but the name and the files still go to everyone who can see the record. If the confidential part comes with documents, or with words that end up in names, give it its own object. The new object gets its own permissions, its own sharing and its own files.

That isn’t “always create another object.” Another object costs a relationship, a second place to report on, and a second security model. The Data Architect course weighs that trade-off in its data security chapter. But when the confidential part has files, splitting the object is usually the only design that holds.

Where does it bleed? A checklist

Before you sign off on any sensitive data, ask where else it shows up:

• List views, reports and dashboards. Is the field taken away with field-level security, not just hidden on the page?
• Global search. Search for a sensitive value as a user who shouldn’t see it. What comes back?
• The API. Which integration users and tools can read the field? Chapter 2’s integration users count here.
• The name. Could a sensitive word end up in the record’s name?
• Lookups. Is Require permission to view record names in lookup fields on?
• Files. Can people attach documents to this record, and who can see the record?

Click to enlarge

What an architect decides here

• For every sensitive field, that field-level security, not the page, takes it away from those who shouldn’t see it.
• How sensitive records are named, and whether an auto-numbered name is safer.
• Whether Require permission to view record names in lookup fields is turned on.
• Which objects can have files attached, and whether a record’s audience is the right audience for its files.
• When confidential data, especially with documents, gets its own object.
• That someone searches as a restricted user before go-live, and writes down what comes back.

Beyond the exam: what AI changes. Data bleed gets faster with AI. A person has to think of the right search; an agent asked a broad question searches everything it can reach, including the files on the records it can see, and summarizes what it finds. Whatever bleeds to a user bleeds to an agent running as that user, in seconds and in plain language. Chapter 20 covers agents and grounding.

Explore

• Ways to Control User Access to Fields (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Fields Required for Creating Custom Objects (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Set File Sharing to Inherit Record Permissions (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Make a File Private on a Record (opens in a new tab), Salesforce Help (checked 2026-11-01)
• What Determines Field Access? (opens in a new tab), Salesforce Help (checked 2026-11-01)