Library
A library in Salesforce is a permission-scoped container for files in Salesforce Files and the older Salesforce CRM Content product.
Definition
A library in Salesforce is a permission-scoped container for files in Salesforce Files and the older Salesforce CRM Content product. Each library has its own membership list and its own library permission, so the people who can read, upload, edit, and manage files are controlled at the library level rather than by the org-wide sharing model. In the data model a library is a ContentWorkspace record, and the files inside it are ContentDocument records with one or more ContentVersion revisions.
A library is the right place to organize files by team, project, or function while keeping a clear line between who can edit and who can only view. Members can be individual users, public groups, or roles, and each member is assigned one library permission such as Viewer, Author, or Library Administrator. Libraries can stay internal, or they can be shared with Experience Cloud customer and partner users when you need to publish files outside the company.
How Salesforce libraries control access to files
Library permissions, not record sharing
The thing that makes a library different from a folder is the library permission. A library permission is a named group of privileges that you assign to each member, and the same user can hold a different permission in every library they belong to. If your org was created after the Spring '09 release, three permissions already exist: Library Administrator, Author, and Viewer. Viewer is read only. Author can add and edit content. Library Administrator can do everything, including managing members and deleting the library. You are not limited to those three. You can build custom library permissions by toggling individual privileges, which is how you give a team upload rights without handing over membership control. One important boundary: library permissions do not apply to personal libraries. Every Salesforce CRM Content user gets a personal library where they can save files regardless of any library permission, so personal libraries sit outside this access model entirely. This separation keeps a user's private drafts away from the shared, governed libraries the team works in.
The privileges that define a permission
When you create or edit a library permission, you turn privileges on and off one at a time. Manage Library is the master switch: it lets a member perform any action in the library, including editing the name and description, adding or removing members, and deleting the library. Add Content lets a member publish new files, upload new versions, and restore archived content, while Add Content on Behalf of Others lets that member choose a different author at publish time. Archive Content and Delete Content control whether a member can pull files out of circulation. Feature Content marks files as featured so they surface first. Tag Content allows tagging during publish or edit, and Organize File and Content Folder lets a member create, rename, and delete folders. There are also comment privileges (View Comments, Add Comments, Modify Comments) and sharing privileges. Deliver Content lets a member create a content delivery, and Attach or Share Content makes a library file accessible in Chatter. Mixing these privileges is how one library can be tightly locked down while another stays open for collaboration.
Salesforce Files and legacy CRM Content
Two products share the library concept, and the names get used interchangeably in the documentation. Salesforce CRM Content is the older file-management product that introduced libraries as the permission boundary for files. Salesforce Files arrived later with Chatter as the modern file layer, and over time the two converged onto a single data model. Today an admin manages everything from the Files Home tab in Lightning Experience, where existing CRM Content libraries appear alongside newer ones under a Libraries section. Underneath, both read from the same objects. A library is a ContentWorkspace, a file is a ContentDocument, each saved revision is a ContentVersion, and the link that places a document into a public library is a ContentWorkspaceDoc. This shared model is why a file uploaded through the modern Files UI behaves the same as one published in classic CRM Content. The practical takeaway is to treat Salesforce Files and CRM Content as one system. When a help article switches from one name to the other, it is describing the same libraries, the same membership, and the same permissions.
Versioning and the audit trail
Files in a library are versioned, and that is one of the strongest reasons to keep important documents in a library rather than as a loose attachment. When someone uploads a new version of an existing file, Salesforce does not overwrite the old one. It creates a new ContentVersion record and keeps the previous versions in the file's history. Members see the current version by default and can open older versions from the version history when they need to compare or roll back. This matters for any document that changes over time, such as a price list, a contract template, or a brand asset, because the full lineage stays attached to one ContentDocument instead of scattering across separate uploads. The history view shows who changed what and when, which gives you an audit trail without extra configuration. For teams that care about which copy is the source of truth, a versioned library file removes the guesswork. There is exactly one current version, and every prior state is still recoverable rather than lost the moment a newer file lands on top of it.
Sharing libraries with Experience Cloud
Libraries are not only an internal tool. They are the standard way to publish files to external audiences through Experience Cloud. A library administrator adds the relevant external user license types as members, gives them an appropriate library permission, and those community users then see and download files according to that permission. This is the common pattern for sharing branded collateral, product images, contracts, or onboarding documents with customers and partners without emailing attachments around. Files Home helps you keep internal and external members distinct: external users automatically receive an external badge so an admin can tell at a glance who is a partner, customer site member, or portal user. The right approach is to treat customer-facing libraries deliberately. Membership should use the community user license types rather than internal users, and the content itself should be sanitized for an outside audience. A library built for staff often contains internal notes or draft material that should never reach a customer, so a separate, purpose-built library for external sharing keeps the two worlds from bleeding into each other.
Files Connect and external sources
A library does not have to store its files inside Salesforce. Files Connect lets Salesforce surface content from external systems such as Google Drive, Microsoft SharePoint Online, OneDrive for Business, and Box as if it were part of the Files experience. An admin defines an external data source in Setup, and once it is connected, users can browse, search, and share those external files from the Files tab, feed posts, and global search. For Google Drive, that includes Google documents, spreadsheets, presentations, and drawings. The benefit is reach without duplication. A document that already lives in SharePoint stays there as the system of record, yet a Salesforce user can attach or reference it from a record feed without downloading and re-uploading a copy. Some external sources support write-back and others are read-mostly, so the exact capabilities depend on the source you connect. Files Connect is worth reaching for when a team already keeps its documents in a cloud drive and you want Salesforce users to find them in the same place they find native library files, rather than forcing a migration of content that is fine where it is.
When a library is the right tool
Salesforce gives you several ways to store a file, and a library is not always the answer. Attachments and the old Documents tab still exist, and a file tied to a single record is often simpler as a regular Files attachment on that record. A library earns its place when many people need the same set of files with different levels of access, when those files need versioning and an audit trail, or when you want to publish to Experience Cloud. Think of a library as the team-or-project unit of file governance. A sales enablement library might give the whole sales org Viewer access while a small content team holds Author, so reps always pull the approved deck and only a few people can replace it. A legal library might restrict membership tightly and rely on versioning so the current contract template is never ambiguous. If a file belongs to one record and one person, a library is overkill. If a file belongs to a function and a group of people, the library permission model is exactly what keeps that access intentional as the team and the content both grow over time.
How to create a library in Salesforce
Admins and Library Administrators create libraries from Files Home in Lightning Experience. You give the library a name, optionally brand it with an image, then add members and assign each one a library permission. You need Manage Library checked in your library permission to manage a library after it exists.
- Open Files Home
In Lightning Experience, go to the Files tab and click Libraries in the left panel. This is where every library you can access is listed, including older CRM Content libraries.
- Create the library
Click New Library, enter a name, and optionally upload an image to brand it. The person who creates the library automatically receives administrative rights over it.
- Add members and permissions
Use the library dropdown and choose Manage Members. Add individual users, public groups, or roles, and give each one a library permission such as Viewer, Author, or Library Administrator.
- Add and organize content
Upload files into the library and, if you have the right privileges, tag them and arrange them into folders. Uploading a new version of an existing file keeps the prior versions in history rather than overwriting them.
A clear name for the library, usually by team, project, or function, so members can find it on Files Home.
At least one member, added as a user, public group, or role, since a library with no members beyond its creator has no audience.
Each member needs an assigned library permission (Viewer, Author, or Library Administrator) that sets what they can do in this library.
- Library permissions are per library. The same user can be a Viewer in one library and an Author in another, so assign permissions deliberately rather than assuming a global role.
- Only empty libraries can be deleted. Remove all files first, and clear them from the Recycle Bin if needed, before the delete will go through.
- Personal libraries ignore library permissions entirely. Files a user saves to their personal library are not governed by this membership model.
- You need Manage Library in your permission to add or remove members. A plain Author cannot change who belongs to the library.
Prefer this walkthrough as its own page? How to Library in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Manage Library PermissionsSalesforce
- Manage Library Membership from Files HomeSalesforce
Straight from the source - Salesforce's reference material on Library.
Hands-on resources to go deeper on Library.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Library in Salesforce CRM Content and Salesforce Files?
Q2. Within a Library, what governs whether a member can view, contribute, or fully administer its files?
Q3. How does Files Connect relate to the Library experience in Salesforce?
Discussion
Loading discussion…