Remove a former collaborator from a shared file

To remove a former collaborator from a OneDrive or SharePoint file, open Manage access and remove the permission that gives that named person access. First identify whether the permission is direct, comes from a sharing link, or is inherited from a parent folder or site. Then check the file for any other route that still grants access.

This guide follows Microsoft’s sharing and permissions instructions. It is based on vendor documentation, not hands-on verification.

Find the source of access

Select the file in OneDrive or SharePoint, then select Details to open its pane. Under Has access, select Manage access. If you do not see Details, make sure you have selected just one file. The access indicators vary with the way the file was shared, so inspect the entries that appear.

Look for the former collaborator’s name under Direct Access. Inspect Links as well. A link can be a separate way to reach the file even after the person’s direct permission is removed. If the file is inside a shared folder or site, consider whether that parent grants access. This gives you a decision to make: remove a direct grant at the file, remove the relevant link if the link is the grant, or make the change at the parent if permission is inherited.

Remove the permission that applies

If the person appears under Direct Access, select their name, choose the option to stop their access, and select Apply. Use that person’s entry when your aim is to remove one collaborator. The Stop sharing option is for stopping sharing of the file entirely.

If access comes through a sharing link, open Links in Manage access, select the Remove Link icon beside the relevant link, and confirm Remove. Check which link you are removing before you confirm: removing it ends access through that link for anyone relying on it. It does not remove a separate direct permission, another link, or group access the former collaborator may have.

If the file inherits permission from a parent folder or site, inspect that parent’s grant before changing it. Removing a link on the file will not settle an inherited grant. If a group provides another route, determine whether the person should leave that group or whether this file needs a narrower sharing arrangement. The absence of a file-level entry bearing the person’s name does not, by itself, show that access has ended.

Do not remove a parent or group permission solely to solve one file’s access problem. A parent grant can cover other documents and collaborators. Microsoft’s permission inheritance guide says ordinary parent changes flow to items still inheriting permissions; they do not automatically update items with unique permissions. The same guide separately warns that its Remove User Permissions action can remove that user’s permissions from child items even when inheritance was broken. A folder-sharing option can also explicitly include uniquely permissioned items. Check the exact action and affected scope with the owner or administrator before changing a parent grant.

Check the result

Return to the file’s Manage access view after making the change. Confirm that the direct entry or link you meant to remove is gone, then review the remaining access routes. Look for another sharing link, a group grant, or access inherited from a folder or site. Removing one link is insufficient if another route still gives the person access.

If a parent still grants access, do not mark the removal complete. Have the owner or administrator review the parent and affected child items before changing it. If the relevant grant cannot be safely identified or changed, record that access remains unresolved. Finish only after the file and its parent routes show that the named person no longer has the intended access, without cutting off other collaborators by accident.