Library Permission
A Library Permission is a named set of privileges in Salesforce CRM Content that controls what a member can do inside a particular content library.
Definition
A Library Permission is a named set of privileges in Salesforce CRM Content that controls what a member can do inside a particular content library. It is not a profile or a permission set. It is a separate record, created under Setup, then assigned to each user, public group, or role that belongs to the library. The same person can hold one permission in a Marketing library and a different one in an HR library, because each library carries its own membership list and each membership is tied to a permission.
Every Salesforce CRM Content org created after the Spring '09 release ships with three ready-made library permissions: Viewer, Author, and Library Administrator. You are free to keep those three, edit them, or build your own with a custom mix of privileges. Library Permissions do not apply to personal libraries, since any Salesforce CRM Content user can save files to their own personal library regardless of membership. Behind the scenes each permission is a ContentWorkspacePermission record, so the model is queryable and deployable through the API and metadata.
How Library Permissions actually gate file access
Permission, not profile: where the access really lives
People new to Files often assume a profile or permission set controls who can edit a library. It does not. Access to library content is gated by the Library Permission attached to a member, plus that member's presence on the library's membership list. A user can have a powerful profile and still see nothing in a given library if they are not a member of it. The reverse is also true: a standard user added as a Library Administrator on one library has full control of that library only. This two-part model (you must be a member, and your membership must reference a permission) is the single most important thing to understand. It is why you assign permissions per library rather than once globally. Org-wide user permissions like Manage Salesforce CRM Content do grant a broad override, but the everyday model for normal users is library by library. Plan it deliberately: decide which teams need which libraries, then decide what each team should be able to do once inside.
The three shipped permissions: Viewer, Author, Library Administrator
Three permissions arrive with the org. Viewer is read-only: a Viewer can open, preview, and download files and follow content, but cannot publish or change anything. Author adds the ability to contribute: publish new files, upload new versions, tag content, and edit file details. Library Administrator is the top tier and can perform any action in the library, including renaming the library, adding and removing members, changing member permissions, and deleting the library itself. The names are conventions, not hard-coded roles. Each one is just a checkbox set you can edit. If your Author group should not be allowed to delete content, open the Author permission and confirm Delete Content is unchecked. The defaults are a sensible starting point, but treat them as editable records rather than fixed tiers. Many orgs rename or clone them to match internal language, for example a "Contributor" permission that is Author minus the tagging privilege.
The individual privileges you can mix
When you build or edit a permission, you select from a list of granular privileges. Manage Library is the master switch that allows any action, including editing the library name, managing members, and deleting the library. Add Content lets a member publish new content, upload new versions, and restore archived content. Add Content On Behalf Of Others lets the publisher choose a different author. Archive Content and Delete Content control archiving and permanent deletion. Feature Content marks files as featured. Tag Content allows tagging during publish or edit. Deliver Content allows creating content deliveries from library files. View Comments, Add Comments, and Modify Comments handle the comment thread on files. Organize File and Content Folders lets a member create, rename, and delete folders. Because these are independent toggles, you can craft a permission that, for instance, allows publishing and tagging but blocks deletion and member management. That precision is the whole point of separating permissions from the membership list.
Members: users, public groups, and roles
A Library Permission only matters once it is attached to a member. You add members from the library's Manage Members screen, reached from Files Home by opening the dropdown next to a library and choosing Manage Members. You can add individual users, public groups, or roles, and each addition is paired with one library permission. For libraries with stable membership, individual users are simple to manage. For libraries whose membership rotates, public groups are far easier: add or remove a person from the group and every library that grants access through that group updates automatically. External users picked up through a group receive an external badge on the member list so you can tell partners and portal users apart from internal staff at a glance. Managing membership in Lightning Experience requires the Manage Library privilege in your permission definition; in Salesforce Classic it requires the Manage Salesforce CRM Content user permission. Choose the grouping strategy before the library grows, because retrofitting groups onto a large individual-member list is tedious.
The user permissions that sit above libraries
Separate from per-library permissions, a handful of org-level user permissions act as administrative overrides. Manage Salesforce CRM Content gives broad control across all libraries. Manage Content Permissions lets an admin create, edit, and delete the Library Permission records themselves under Setup. Create Libraries allows creating new libraries. Manage Content Properties and the record-types-and-layouts permission govern the custom fields and page layouts that describe published files. Deliver Uploaded Files and Personal Content controls content deliveries from outside a managed library. These are profile or permission-set permissions, not library-level ones, and they are what you grant to the small group of people who administer the content system as a whole. A practical split is to give a few admins Manage Content Permissions so they curate the permission records, while everyday teams receive only the Viewer, Author, or Administrator permission on the specific libraries they work in. Keep the override permissions tight, since they bypass the careful per-library design.
Querying and deploying through ContentWorkspacePermission
Each Library Permission is stored as a ContentWorkspacePermission record, available in the API from version 40.0 onward. The object exposes the same privileges you see in the UI as boolean fields, such as PermissionsManageWorkspace, PermissionsAddContent, PermissionsArchiveContent, PermissionsDeleteContent, and PermissionsTagContent, alongside Name, Description, and Type. Because the permission is a real object, you can audit it with SOQL, report on which privileges a permission grants, and move definitions between sandboxes. The library itself is a ContentWorkspace record and a member assignment is a ContentWorkspaceMember record that points to both a user (or group) and a permission. That relationship is worth remembering when you debug access: if a user cannot edit, check the ContentWorkspaceMember row to see which permission they actually hold, rather than assuming the library default applies to everyone. The API view also makes it possible to provision libraries and memberships programmatically during an onboarding or a large content migration.
Common access problems and how to read them
Most Library Permission tickets trace back to one of three causes. First, the user is simply not a member of the library, so no permission applies and they see nothing. Second, the user is a member but holds Viewer when they expected Author, so opening works but publishing is blocked. Third, an org-level user permission is missing, for example a content admin who lacks Manage Content Permissions and therefore cannot edit the permission records in Setup. Work the problem in that order: confirm membership, confirm which permission the membership references, then confirm the relevant org-level user permission. Remember that personal libraries ignore all of this; every user can always save to their own personal library. Also recall that the shipped permission names are editable, so a permission literally labelled "Author" might have been altered to remove a privilege. When in doubt, open the permission record under Content Permissions and read the actual checkboxes rather than trusting the name. A two-minute check of membership plus the live privilege list resolves the large majority of these issues.
How to create and assign a custom Library Permission
Create a custom Library Permission when the three shipped permissions (Viewer, Author, Library Administrator) do not match what a team should be able to do. You build the permission once under Setup, then assign it to members on each library. You need the Manage Content Permissions or Manage Salesforce CRM Content user permission.
- Open Content Permissions
From Setup, type Content Permissions in the Quick Find box and select Content Permissions. This page lists every Library Permission in the org, including the three defaults.
- Add a new permission
Click Add Library Permission. Give it a clear Name (for example Contributor No Delete) and an optional Description so future admins know its intent.
- Select the privileges
In the Permissions section, check the privileges this permission should grant, such as Add Content and Tag Content, and leave risky ones like Delete Content or Manage Library unchecked. Save the record.
- Assign it to members
Go to Files Home, open the dropdown next to the target library, choose Manage Members, add the users, public groups, or roles, and pick your new permission for each. They get that access only on this library.
The label that identifies this Library Permission in Setup and on the Manage Members screen. Make it describe the access, not the team.
The set of checkboxes (Manage Library, Add Content, Delete Content, Tag Content, Deliver Content, comment privileges, folder privileges) that define exactly what a member can do.
- A Library Permission grants nothing until it is attached to a member on a specific library; creating the record alone has no effect.
- Manage Library is an all-powerful switch that includes deleting the library and changing members; grant it only to true administrators.
- Editing a default permission (Author, Viewer) changes behaviour everywhere it is assigned, so clone it instead if you only want a variant.
- Library Permissions never apply to personal libraries; you cannot use them to restrict what users save to their own personal library.
Prefer this walkthrough as its own page? How to Library Permission in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Manage Library PermissionsSalesforce
- Create and Edit Library PermissionsSalesforce
Straight from the source - Salesforce's reference material on Library Permission.
Hands-on resources to go deeper on Library Permission.
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 does a Library Permission control for a user in a specific Salesforce CRM Content Library?
Q2. Among the three Library Permission levels, what distinguishes a Library Administrator from an Author?
Q3. Are Library Permissions global or scoped to one Library at a time in a Salesforce org?
Discussion
Loading discussion…