File Owner
A File Owner in Salesforce is the user who has full control over a Salesforce File, including the rights to edit it, delete it, change who it is shared with, and transfer the file to someone else.
Definition
A File Owner in Salesforce is the user who has full control over a Salesforce File, including the rights to edit it, delete it, change who it is shared with, and transfer the file to someone else. By default the File Owner is the person who uploaded the file, and the platform records that user in the OwnerId field on the ContentDocument record. No collaborator or viewer can override what the owner is allowed to do.
File ownership sits at the top of the Salesforce Files sharing model, above Collaborator (view and edit) and Viewer (view only). Most files have exactly one owner for their entire life. Ownership can be moved to another user from the file detail page or programmatically by updating OwnerId, and a System Administrator with the right permission can act on any file regardless of who owns it.
How File ownership controls access, transfer, and cleanup
Where the owner is stored: OwnerId on ContentDocument
Every Salesforce File is really three related records. The ContentDocument is the logical file, each ContentVersion is a saved revision of its bytes, and ContentDocumentLink connects the file to the users, records, groups, and libraries it is shared with. The File Owner is the user named in the OwnerId field on the ContentDocument. When someone uploads a file, the platform sets OwnerId to that user automatically, with no prompt or confirmation step. The owner reference travels with the file even as new versions are added, because versions hang off the same ContentDocument. This matters when you query files in SOQL or report on storage, since grouping ContentDocument by OwnerId tells you who is accountable for each file. It also explains a common surprise: when an integration or automated job creates a file through the API, the running user (often an integration account) becomes the owner, not the person the file was meant for. Knowing OwnerId is the single source of truth keeps ownership questions from turning into guesswork.
Owner-only actions versus Collaborator and Viewer
The whole point of ownership is the short list of things only the owner can do. An owner can delete the file, restore it from the Recycle Bin after a soft delete, change its sharing so that new people gain or lose access, and hand the file to a new owner. A Collaborator can view the file, edit its details, and upload a new version, but cannot delete it or rewrite its sharing for everyone else. A Viewer can only open and download the file. On the ContentDocumentLink, these levels map to ShareType values: V for Viewer, C for Collaborator, and I for Inferred, where the person inherits whatever access they have on the related record. Because the owner sits above all of these, the owner is the person a teammate has to ask when a file needs to disappear or move. If you ever cannot work out why a file persists despite removing shares, check who the owner is first. Removing collaborators never strips the owner of control.
Changing the owner from the file detail page
Day to day, most ownership changes happen in the user interface. From the file detail page in Lightning Experience, the owner (or an admin) opens the sharing controls and either edits who can access the file or transfers it outright. The interface lets you set each person or group as a Viewer or a Collaborator, and the owner decides whether the previous owner stays on as a Collaborator or is removed entirely once a transfer completes. This is where business policy shows up. A marketing team might keep the original creator as a Collaborator so they can still update the asset, while a legal or HR team might require the prior owner to lose access the moment the file changes hands. The action is deliberate by design. Salesforce never silently reassigns a file, so a file keeps its original owner until a human or an automated job moves it. That is convenient while the owner is active, and a problem the day they leave.
Transferring ownership in bulk through the API
When you need to move many files at once, the file detail page is too slow, so teams update OwnerId directly. Because OwnerId lives on ContentDocument, a simple update DML on those records reassigns ownership in bulk, and the same thing can be done with Data Loader by exporting ContentDocument rows and reimporting them with a new OwnerId. This is the standard pattern for offboarding. You query every ContentDocument owned by the departing user, set OwnerId to a successor or to a long-lived service account, and commit the change. Be deliberate about what happens to the old owner afterward. Reassigning OwnerId gives the new user full control, but it does not automatically preserve the prior owner as a Collaborator, so add a ContentDocumentLink for them if continued access is required. Test the job against a sandbox first, because a careless bulk transfer can sweep up personal files or files the successor was never meant to see. Treat large ownership moves as a reviewed, repeatable process rather than a one-off script.
User deactivation and orphaned files
Files do not have an owner reassigned for you when their owner is deactivated. The ContentDocument keeps pointing at the now-inactive user, and the file becomes orphaned: still stored, still consuming file storage, but tied to an account nobody logs into. Sharing that was inferred or set explicitly continues to work, so collaborators may still reach the file, yet there is no active owner to delete it, move it, or sign off on a change. Mature orgs solve this with an offboarding routine that runs before or right after deactivation. A common approach is an Apex process that fires when a User record flips to inactive and reassigns that user's ContentDocument records to a designated successor or a generic files account. The key is to run the cleanup as a planned step, not to discover orphaned files months later during a storage audit. Building the transfer process before anyone leaves means a departure becomes a checklist item instead of a scramble to recover access to important documents.
Administrator override and shared ownership
Two patterns sit at the edges of single ownership. The first is the administrator override. A user with Modify All Data can edit or delete any file regardless of who owns it, and View All Data grants read access across files for reporting and audits. These permissions exist so admins can keep the org clean and meet compliance requests, but they bypass the normal sharing model, so use them sparingly and record why each override happened. The second pattern is shared ownership. Although a file has one canonical OwnerId, you can grant additional users owner-like reach through ContentDocumentLink records, and on a related record a ShareType of I lets people inherit broad access from their record permissions. This is uncommon in practice. Multiple people with near-total control over a single file introduce coordination questions, such as who is allowed to delete it or change its sharing, so most teams keep one clear owner and use Collaborator access for everyone else. Reserve shared control for the rare case that genuinely needs it.
How to change or transfer a File Owner
Changing who owns a file, or transferring it to a teammate, is done from the file detail page in Lightning Experience. The owner or a System Administrator can do this. Use it when a file needs to move because someone changed roles or is leaving.
- Open the file detail page
Click into the file from the Files related list, the Files tab, or a feed post so the file preview and details are showing.
- Open the sharing controls
Use the file's action menu to open Share or Edit File Access. You will see the current owner plus everyone the file is shared with and whether each is a Viewer or Collaborator.
- Transfer the file or adjust access
Choose the Change Owner action to hand the file to a new user, or add people and set them as Viewer or Collaborator. Decide whether the previous owner stays as a Collaborator or is removed.
- Save and confirm
Save the change. Reopen the sharing controls to confirm the new owner is listed and that access levels for everyone else match what you intended.
Full control: edit, delete, restore, transfer, and change sharing for everyone. Stored as OwnerId on the ContentDocument.
View, edit details, and upload new versions. Cannot delete the file or change sharing for other users.
Open and download only. The lowest access level in the Files sharing model.
Access is inferred from the user's permission on the related record, so it rises or falls with record access.
- Salesforce never reassigns a file automatically when its owner is deactivated, so the file stays orphaned until someone transfers it.
- Files created through the API are owned by the running user, which is often an integration account rather than the intended person.
- Transferring ownership does not keep the previous owner as a Collaborator unless you add a ContentDocumentLink for them.
- Only the owner and admins with Modify All Data can delete a file; removing collaborators never strips the owner's control.
Prefer this walkthrough as its own page? How to File Owner in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on File Owner.
Hands-on resources to go deeper on File Owner.
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. By default, who becomes the File Owner when a Salesforce File is uploaded?
Q2. Which action is reserved exclusively to the File Owner (or an admin with override permissions)?
Q3. What operational problem arises when a File Owner is deactivated without first transferring ownership?
Discussion
Loading discussion…