Remove someone's OneDrive or SharePoint access: trace every permission route

To remove someone’s access to a file, check every route that lets them reach it: direct permission, sharing links, and access inherited through a folder, site, or group. Deleting one link may leave a group grant alive. Removing a person’s direct permission may leave a link addressed to them. Record each surviving route for that person and file before marking the removal complete.

Identify the file, person, and scope

Start with the exact file URL and the person’s invited or signed-in email identity. A display name alone may not identify the account whose access you need to change. Record whether the request covers one file, a folder, or an entire collaboration. That choice determines who should approve the change and who else it might affect.

For a single file, its owner can select the file, open Details, find Has access, and choose Manage access. Interfaces differ. For a direct grant, select the person and remove access, then Apply. For a link, open Links, remove the relevant link and confirm. Stop sharing is the whole-file control; use the individual route when other collaborators must remain. Microsoft’s OneDrive and SharePoint sharing guide

If you cannot see or manage the relevant permission, stop at that boundary. An escalation note can be precise: “Please check Morgan’s access to Launch-notes.docx. I can see a direct Edit grant, but Campaign Members may also grant Read through the parent folder. The requested scope is this file only; the group owner needs to confirm the intended audience.” That gives the next owner a decision to make without claiming the file is already restricted.

A direct grant and a named link

Consider a modeled file, Budget-review.xlsx. Morgan, a former contractor, has direct View access and is also a recipient of Specific people link L1. Priya still needs access through L1.

Stage	Morgan’s listed routes	Priya’s listed route
Before	Direct View and L1	L1
After removing direct View	L1	L1
Intended recorded state	None in this model	L1 or a replacement link

Removing Morgan’s direct View grant addresses only one of the two listed routes. Inspect L1’s recipients next. If the available control lets the owner remove Morgan while retaining Priya, use it and check the resulting recipient list. If it does not, create a suitable replacement for Priya, deactivate the old L1, and give Priya the new link. Do not assume every interface lets an owner change an existing link’s permissions in the same way. Microsoft’s sharing guide

In this example, Morgan starts with two routes. After the first action, one remains. After the second, none of the listed routes addresses Morgan, while Priya keeps one. An owner checking a real file still needs to inspect any folder, site or group permission omitted from this small example.

A group grant from a parent folder

A second modeled file, Launch-notes.docx, gives Morgan direct Edit access. Morgan also belongs to Campaign Members, a group with Read access through the parent folder. Removing direct Edit leaves group Read. Deleting a sharing link would not address that group route.

If the request only says “remove Morgan,” ask whether that covers the campaign or just this document. If Morgan is leaving the whole campaign, the group owner can assess their membership across the collaboration. If Morgan should lose access only to Launch-notes.docx, an authorized owner needs to arrange the intended audience for that file while preserving other members’ access. Removing the entire group from a site to solve a one-file request could affect people and files outside the request. SharePoint team and group permissions are connected; for a Teams-connected site, Microsoft directs owners to manage the team through Teams, including permissions for private and shared channels. Group removal can also affect connected services. Microsoft’s modern sharing guidance

Inheritance matters here. A file or folder can inherit permissions from its parent or have unique permissions. An ordinary parent permission change propagates to children that inherit it. Do not turn that into a blanket rule that an item with unique permissions is immune to every parent-level action: Microsoft’s specific Remove User Permissions action warns that removal can affect children, including children with broken inheritance. Restore inheritance deletes an item’s unique permissions, so it is not a harmless reset when those permissions were set for a reason. Microsoft’s SharePoint permissions guide

In the modeled Launch-notes.docx case, the final state remains unresolved until the authorized owner decides and carries out the appropriate group or file scope change. Removing direct Edit alone does not support a “Morgan has no access” entry.

An Anyone link beside a named link

For modeled Pricing-draft.pdf, link L3 is a Specific people link for Morgan and Priya. Link L2 is an Anyone link. Removing Morgan from L3 leaves L2: whoever holds an Anyone link can use that route, so its owner cannot revoke it for Morgan alone while leaving the bearer link active. Microsoft’s modern sharing guidance

If the intended audience is limited to named people, close L2 for every holder and arrange permitted access for those who should continue. Also check L3’s resulting recipients or its replacement. The example then has no listed link route for Morgan. It still cannot establish that Morgan has no group or site route; those must be checked separately. “Unknown” is a useful record when a route has not been inspected. It is not a zero.

What the access screen may still show

After unsharing, a Limited access entry may remain visible. Microsoft explains that such an entry does not, by itself, grant access to other unshared items. For example, seeing Morgan under Limited access after removing the file grant calls for a file-level check. Deleting the directory entry solely because the name remains would address a different object. Microsoft’s SharePoint permissions guide

Cloud access and a copy already on a device are separate questions. Microsoft says its sync app can keep files on a local disk for offline work. Revoking ordinary sharing addresses future cloud access; it does not prove that an ordinary, unprotected copy someone already downloaded was erased. Record that copy issue separately for the file owner if it matters to the request. Microsoft’s file collaboration guidance

Record what was actually checked

Use the blank access route worksheet to record the file URL, exact target identity, route origin, audience, requested scope, approving owner, observed before and after permissions, and any route still present or unknown. The case CSV shows the three modeled cases as nine before, action, and after records. Its counts describe the examples, not account results.

Save the trace with the file owner’s records so a later reviewer can distinguish a completed removal from a handoff. For each route, record where the grant was made and the person who can change it. An owner can record “direct grant removed” immediately; a pending group-owner action needs its own unresolved entry. Use a separate row for each old link instead of writing “links checked” without identifying them.

A partial-progress note could read: “For Budget-review.xlsx and Morgan’s specified email identity, the owner observed the direct View grant removed and L1 no longer addressed to Morgan. Priya’s intended link route remained. No recipient sign-in check was performed; folder, site, and group routes are still unknown.” That note records progress and leaves the task open. A completed note needs the remaining routes resolved and the exact file and identity covered by the observation. If a cooperating recipient checks access, they should use their own session. A continuing colleague opening the file confirms their retained access; it does not prove the former collaborator is blocked. Do not request another person’s credentials.

The Microsoft instructions were checked October 7, 2026. The workbook, document and PDF cases are illustrative permission states, not live tenant test results.