File Collaborator
A File Collaborator in Salesforce is a user or group that has been granted view-and-edit access to a Salesforce File.
Definition
A File Collaborator in Salesforce is a user or group that has been granted view-and-edit access to a Salesforce File. A Collaborator can open the file, download it, post comments, and upload new versions. What a Collaborator cannot do is delete the file or hand out access to other people. Those rights stay with the file owner.
Collaborator is one of the named sharing levels for Salesforce Files, sitting above Viewer (which is read-only) and below the owner. Under the covers, the access is stored on a ContentDocumentLink record whose ShareType field holds the value C. That link ties the file to a user, a group, a record, or a library, and the ShareType on each link decides how much access that audience gets.
How Collaborator access actually works on a Salesforce File
Viewer, Collaborator, and the file owner
Salesforce Files use a small set of access levels, and Collaborator is the middle one. A Viewer can open, preview, download, and comment on a file. A Collaborator can do all of that and also change the file by uploading a new version. The owner is the person who originally uploaded or created the file, and the owner keeps the strongest set of rights, including deleting the file and managing who else can see it. The practical reason this matters is that "share a file" is not a single action. When you share, you are choosing a level. Hand a customer a read-only copy and you pick Viewer. Bring a teammate into the editing loop and you pick Collaborator. The owner stays the owner unless ownership is explicitly transferred. Keeping these three levels straight is the difference between a contributor who can revise a deck and an outsider who can only read it. Most internal collaboration lands on Collaborator, because edit access is usually the point of sharing a working document with a colleague.
ContentDocumentLink and the ShareType field
Every share of a Salesforce File is a row in the ContentDocumentLink object. The record points a ContentDocument (the file) at a LinkedEntityId (the audience) and carries a ShareType that sets the access level. ShareType has three documented values. V means Viewer, so the user can view but not edit. C means Collaborator, so the user can view and edit. I means Inferred, where the access is decided by the related record or, for a library share, by the permissions the user holds in that library. This is the data model worth memorizing, because it explains a lot of behavior. There is no ShareType value for "owner"; ownership is a separate concept tracked on the file itself, not on the link. When you grant Collaborator access through the UI, Salesforce writes a ContentDocumentLink with ShareType set to C behind the scenes. When you read that same value back through SOQL or the API, C is exactly what you see. Knowing the field saves you from guessing why one share allows edits and another does not.
What a Collaborator can and cannot do
A Collaborator has a clear, bounded set of abilities. They can view and preview the file, download it, add comments, and upload new versions. Uploading a new version creates a fresh ContentVersion record while keeping the same ContentDocument, so the version history grows and earlier versions stay available. A Collaborator can also generally manage the basic content details that come with editing, such as renaming through a new version. The limits are just as important. A Collaborator cannot delete the file, cannot transfer ownership, and cannot extend access to new people. Those are owner-level actions. This boundary is deliberate. It lets you bring contributors into a document without handing them the keys to remove it or quietly widen the audience. If a teammate needs to revise a contract draft, Collaborator gives them edit rights while the owner stays in control of deletion and re-sharing. If that teammate later needs to manage sharing too, the answer is to transfer ownership or coordinate through the owner, not to stretch the Collaborator level past what it covers.
Sharing a file with a group of Collaborators
A ContentDocumentLink can point at a public group, not just a single user. When you add a group as a Collaborator, every member of that group inherits Collaborator access to the file. This is the standard way to handle team-based file sharing. Instead of creating one link per person, you create one link for the group, and membership does the rest. The payoff shows up over time. Add a marketing public group as a Collaborator on a set of campaign assets, and anyone in that group can edit those files. When someone joins the team and is added to the group, they pick up access automatically. When they leave the group, the access goes with them. You are not chasing down individual share records every time the roster changes. For files that a whole department touches, group-based Collaborator access is far less work to maintain than a pile of per-user links, and it keeps access tied to a single source of truth, which is group membership.
Files on records and inferred access
When a file is attached to a record such as an Account, an Opportunity, or a Case, the people who can see that record often need the file too. Salesforce supports this through inferred access, the ShareType value I, where the file's access is driven by the related record rather than by an explicit Viewer or Collaborator grant. Admins get a setting that controls this. The "Set File Sharing to Inherit Record Permissions" option makes a file attached to a record follow the record's sharing instead of defaulting everyone to a fixed level. With it on, a user who has edit access to the parent record can get a matching level of file access, and a user with read-only record access gets read-only file access. This keeps file visibility lined up with record visibility, which is usually what compliance and security teams want. Even with inheritance in play, an owner can still add an explicit ContentDocumentLink with ShareType C to give a specific person Collaborator rights that go beyond what the record alone would grant. Inherited access and explicit Collaborator shares coexist on the same file.
Changing or removing Collaborator access
Collaborator access is not permanent. From the file's sharing settings, the owner can change a person from Collaborator down to Viewer when edit rights are no longer needed, or remove the share entirely. Through the API or Apex, the same outcome comes from updating the ContentDocumentLink's ShareType or deleting the link record. The change takes effect right away. Once the link is gone or downgraded, the user loses the matching rights on their next interaction with the file. One thing that does not change is history. If a former Collaborator already uploaded versions or left comments, those stay in the file's record after their access is pulled. Removing a Collaborator stops future edits; it does not roll back past contributions. That is why a periodic review of who holds Collaborator access on sensitive files is worth doing. Long-lived documents tend to collect Collaborators who were added for a one-time task and never removed. Trimming that list keeps the editable audience honest and reduces the chance that a stale share becomes a quiet security gap.
How to grant File Collaborator access
Granting Collaborator access is a sharing action on an individual file. The most common path is the Share dialog in Lightning Experience, where you pick the people or groups and set their access level to Collaborator. Developers can do the same thing in bulk by inserting ContentDocumentLink records with ShareType set to C.
- Open the file's sharing settings
Find the file in the Files tab, on a record's Files related list, or in a library. Click the file, then choose the share or sharing settings option to open the Share dialog for that specific file.
- Add the person or group
In the dialog, search for the user or public group you want to bring in. Adding a public group grants the access to every member of that group at once, which is the easier choice for team-wide files.
- Set the access level to Collaborator
Choose Collaborator as the access level so the audience can both view and edit (upload new versions). Pick Viewer instead when you only want read-only access for that person or group.
- Save and confirm
Save the change. Salesforce writes a ContentDocumentLink with ShareType C for that audience. Reopen the sharing settings later to change a Collaborator to Viewer or to remove access when it is no longer needed.
Set to Collaborator for view-and-edit, or Viewer for read-only. Collaborator maps to ShareType C; Viewer maps to ShareType V on the ContentDocumentLink.
Choose a user, a public group, a record, or a library. Group shares spread Collaborator access to all current and future members of that group.
An org setting that lets files attached to records follow the record's sharing (inferred access, ShareType I) instead of a fixed level. Enable it to keep file visibility aligned with record visibility.
A separate option that generates a shareable URL for read-style access. Use it for quick distribution, but use named Collaborator shares when you need people to edit and be tracked individually.
- Collaborator cannot delete the file or re-share it. If a contributor needs those rights, transfer ownership rather than trying to stretch the Collaborator level.
- Adding a public group as a Collaborator gives every member edit access. Audit the group's membership before sharing a sensitive file with it.
- Removing a Collaborator stops future edits but does not delete the versions or comments they already added. The file's history keeps those contributions.
- ShareType I (Inferred) is not the same as Collaborator. Inferred access comes from the related record or library; Collaborator (C) is an explicit view-and-edit grant.
Prefer this walkthrough as its own page? How to File Collaborator in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on File Collaborator.
Hands-on resources to go deeper on File Collaborator.
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 can a File Collaborator do that a File Viewer cannot in Salesforce Files?
Q2. Which ContentDocumentLink ShareType value grants Collaborator access to a file?
Q3. How does adding a Public Group as a Collaborator on a file behave?
Discussion
Loading discussion…