Skip to content
SteveTechArcSteveTechArc Courses

Who Can See a File? Owners, Records, Libraries and Public Links

Module 2 of 8 in the chapter Files, Folders, Reports and Other Data, chapter 12 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: Who can see a file in Salesforce, and how did they get it?

In my class, when we got to file security, I asked it as a question: who can see my files if I make them private, if I make them privately shared, or if I share them with everyone in my company? It sounds like a simple question. It isn’t, because a file doesn’t live in one place. It can be on a record, in a library, in a group, and behind a link, all at once.

And none of that is the share table. A file has its own sharing. Chapters 5 to 11 can be perfect, and a file can still walk out of the building.

Three settings

Section titled “Three settings”

Every file has one of three sharing settings, and Salesforce shows it on the file: “Your files in Salesforce can be private to you, privately shared, or visible to your entire company” (Who Can See My File? (opens in a new tab), Salesforce Help, checked 2026-11-07).

  • Private. “It hasn’t been shared with anyone else besides the owner.” You upload it in Files home, or put it in your private library.
  • Privately shared. “The file has been shared only with specific people, groups, or via link.” Posting it to a private group, a record’s feed or a shared library also makes it privately shared.
  • Your company. “All users in your company can find and view this file.” That’s what happens when it’s posted to a feed everyone can see, a profile, or a public group.

Notice the second one. “Shared via link” is in the same bucket as “shared with specific people.” The setting tells you it’s not company-wide. It doesn’t tell you how many people outside the company have the link.

Four ways into a file

Section titled “Four ways into a file”

So who can see a given file? Ask how it can be reached. There are four ways in.

Four ways into a file Four ways into a file. Shared directly, with people and groups: shared with specific people; posted to a group, private or company-wide; viewers can share it again. On a record, set by File Privacy on Records: anyone who can see the record, unless the file is Private on Records; only the owner or an admin changes it. In a library, for library members: a permission per library; add a public group, not each user; a guest member makes the library public. By a link, for anyone who has it: anyone with the link can download; it expires in 90 days by default; folder links have no password and no expiry. Footnote: users with View All Data or Modify All Data see files they don't own, except in a private library. {"author": "Steve Simpson", "blueprint": "1.0.1", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-SVA-OD-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Shared directly people and groups Shared with specific people Posted to a group: private, or company-wide Viewers can share it again On a record File Privacy on Records Anyone who can see the record Unless it's Private on Records Only the owner or an admin changes it In a library library members A permission per library Add a public group, not each user A guest member makes it public By a link anyone who has it Anyone with the link can download Expires in 90 days by default Folder links: no password, no expiry Users with View All Data or Modify All Data see files they don't own, except in a private library. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Shared directly

Section titled “Shared directly”

The owner shares the file with people or groups. If it’s shared with a private group, “only members of the group can find or view the file” (Who Can See My File?). Module 3 takes groups apart.

On a record

Section titled “On a record”

Attach a file to a record, and the record’s sharing usually decides who sees it there. That’s the one place the work of chapters 5 to 11 reaches a file. Salesforce gives each file a setting for it, File Privacy on Records, with two choices: “Visible to Anyone With Record Access lets anyone who can see the record also see this file attachment,” and “Private on Records lets only the file owner see the file” on the record (Make a File Private on a Record (opens in a new tab), Salesforce Help, checked 2026-11-07).

“Only admins and file owners can change the value.” And one warning from the same page: “On private files, file metadata isn’t also private.” Someone who can’t open the file can still see things about it, such as who’s following it.

For external users, Salesforce adds: “External users see files posted to records they have access to, unless the record post was marked Internal Only” (Who Can See My File?). Part 3 covers sites.

In a library

Section titled “In a library”

A library is a shared shelf with its own members. “A library permission is a group of privileges assigned to each Salesforce CRM Content library member,” and “The same user can have a different library permission in each library.” Orgs come with three: Library Administrator, Author and Viewer (Manage Library Permissions (opens in a new tab), Salesforce Help, checked 2026-11-07).

Two lines from the library page are worth teaching. First, the same advice as for buckets in chapter 11: “If you have many Salesforce CRM Content users, create a public group and add it to a library rather than adding users to the library individually.” Second, a warning: “When you add a guest user as a member of the library, the library and files become publicly accessible” (View and Edit Libraries (opens in a new tab), Salesforce Help, checked 2026-11-07).

Section titled “By a link”

A public link is the widest door. “Creating a public link generates a URL that you can copy and share with anyone inside or outside your company,” and “anyone who has the link can view and download the file.” For a single file, “Expiration dates are on by default and set 90 days in the future,” and you can turn on a password (Share Files Via Link (opens in a new tab), Salesforce Help, checked 2026-11-07).

Folders are different. You can make a public link to a library folder, but “Public links to folders don’t have password protection or link expiration.” Salesforce’s own advice: “Any time confidential documents are shared, we recommend requiring password protection.” Who can make links is a permission: “Create Public Links”, or “Create Content Deliveries” for the tracked kind. And for files in a library, the library decides, not the permission: “Deliver Content must be enabled for the user in the library” (Enable Content Deliveries and Public Links (opens in a new tab), Salesforce Help, checked 2026-11-07).

Here’s the architect’s point. A link can’t be taken back from the person who has it, only deleted for everyone. “After you delete a link, it no longer provides access to the file” (Share Files Via Link). Until then, anyone it was forwarded to has the file.

And the overrides

Section titled “And the overrides”

The admins with the big permissions see more, with one exception. “Users with View All Data permission can view and preview files that they don’t own,” and Modify All Data can do nearly anything to them. “However, if the file is in a private library, then only the file owner has access to it” (Who Can See My File?).

Owner, collaborator, viewer

Section titled “Owner, collaborator, viewer”

Once someone can see a file, what can they do with it? Salesforce gives three levels: owner, collaborator and viewer (Who Can See My File?).

Owner, collaborator, viewer Owner, collaborator, viewer. The owner can do everything: everything a collaborator can, make the file private or restrict access, and delete it. A collaborator can edit and share: everything a viewer can, upload a new version, edit the details, and change others' permission. A viewer can see and pass on: view, preview and download, share it with others, and attach it to a post. Footnote: prevent others from sharing stops new shares, not old ones; since Spring '26, the Delete Salesforce Files permission lets others delete without Modify All Data. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-SVA-OD-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Owner everything Everything a collaborator can do Make private, restrict access Delete the file Collaborator edit and share Everything a viewer can do Upload a new version, edit details Change others' permission Viewer see and pass on View, preview, download Share it with others Attach it to a post Prevent others from sharing stops new shares, not old ones. Since Spring '26, Delete Salesforce Files lets others delete without Modify All Data. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Look at the viewer’s column in Salesforce’s table: view, download, share, and attach to a post. A viewer can pass the file on. That’s how a file shared with three people ends up with thirty.

The owner can stop it. “You can prevent others from sharing and unsharing a file that you own. Preventing others from sharing or unsharing doesn’t affect existing shares.” Salesforce’s example is exactly the case: “I’m okay with members of the group having access to the file, but I don’t want them to share it further” (Prevent Others from Sharing and Unsharing a File (opens in a new tab), Salesforce Help, checked 2026-11-07).

Who can delete a file

Section titled “Who can delete a file”

In Salesforce’s table, only the owner can delete a file. That used to leave admins a bad choice. In the words of Salesforce’s admin blog: “if a user needed to delete a file they didn’t own, you had only two choices: Have them ask the file owner or grant them the Modify All Data permission—which is a major security risk.” Spring ‘26 added a third: “With the new Delete Salesforce Files permission (via a permission set or profile), you can empower specific users (like team leads or data cleansers) to manage files they have access to” (Jen’s Top Spring ‘26 Features for Admins (opens in a new tab), Salesforce Admins blog, checked 2026-11-07).

That’s least privilege, the habit from Part 1. If someone’s only reason for Modify All Data was cleaning up files, give them this permission instead, and take the big one away.

Test knowledge. Know the three file settings, private, privately shared and your company, and that file sharing isn’t the share table. Know that File Privacy on Records decides whether a file attached to a record is visible to anyone with record access or only to its owner. Know that a file in a private library is seen only by its owner, even by users with Modify All Data. A likely area, not a known question.

What an architect decides here

Section titled “What an architect decides here”
  • Which files may be shared with the whole company, and which must stay on records or in libraries.
  • For sensitive files on records, whether File Privacy on Records should be Private on Records.
  • Each library’s members, as public groups, and their library permissions; and that no guest user is a member of a library that isn’t meant to be public.
  • Who gets Create Public Links and Create Content Deliveries, whether links need a password, and how long they last.
  • Which owners should prevent others from sharing their files.
  • Who gets Delete Salesforce Files, so nobody holds Modify All Data just to clean up files.

Beyond the exam: what AI changes. An agent that searches files as its user finds every file that user can see: on records, in libraries, in groups, and everything shared with the company. A file someone shared company-wide years ago, and forgot, is now one question away. And if an agent can create public links, it can send a file outside the company. Before an agent works with files, check what’s shared with the company, and don’t give its user Create Public Links unless that’s its job. 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.