Remove a person from sharing links
Keep the links and the other recipients
The offboarding tool. When somebody leaves, they are usually still on dozens of specific-people sharing links scattered across libraries. This finds the links that grant that exact person access and removes only them from them, leaving the links working for everybody else.
What it does
- Every specific-people link that directly grants that one person access.
- Who else is on each link, before and after, so you can see nothing else changed.
- Whether each removal was verified against the live link afterwards.
- Optionally, direct permission assignments to that person as well as links.
How it runs
- Sign in and choose what to scan. Sites or libraries.
- Name the person. Picked from the directory, so it is an exact identity rather than a text match on a name.
- Review what was found. Per link, with the recipient list before and after.
- Confirm, then it runs. Each removal is verified by re-reading the link. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
The person is matched by identity, never by display name. When the directory gives an object id, a link recipient matches only on that id; otherwise it matches on email address or user principal name, compared exactly apart from letter case, and a guest account's own address is recognised as well. Only Specific People links are considered, and only links made on the item itself: organisation links, anonymous links and links inherited from a parent folder are never matched, whatever else is set.
The scan reads every file and folder in the chosen libraries that passes your filters, reads its sharing permissions, and keeps the links that have this person as a recipient. Nothing changes during the scan. If you also asked for direct assignments, a permission granted directly on the item to this person alone, not through a link, a group or inheritance, is listed too.
Before each change the link is read again live. If it has gone, or the person is no longer on it, nothing is sent and it is recorded as already absent. If it is no longer a Specific People link made on that item, nothing is sent and it is recorded as failed. Otherwise the full recipient list is written to a run log on this computer, only that one recipient is removed, and the link is read back. It counts as removed only when the person is gone and every other recipient from before is still there. If the person was the last recipient, SharePoint deletes the link, and that is recorded. If other recipients disappeared too, it is recorded as a critical verification failure. The read-back runs even when the request failed or its answer was lost, so a change that did land is not reported as failed.
Direct assignments are handled after the links, and not at all if the links pass was stopped. One is deleted only when the live re-read shows it belongs to exactly this one person; a permission that covers anyone else is left alone and recorded as failed. After each delete, every other permission on the item is checked to still be there.
An item that fails or cannot be verified is listed with the reason, and the run moves on. A Stop, a lost sign-in, or the run log failing to write ends the run before the next item; whatever was already removed stays removed and is in the report. Access through groups, inheritance, the site or library, or any other link is never touched. The report goes into Report History and the run into the tool's History.
What you get
An Excel workbook, named like shared-links-contoso-projects-20260901-1422.xlsx, kept in Report History whether or not you save it. Recipients before and after are the columns that prove only the one person changed.
Sharing Links sheet
One row per link acted on.
| Column | Example |
|---|---|
| Library | Shared Documents |
| Item path | Clients/Northwind/Contract.pdf |
| Target person | Jonas Olsen |
| Recipients before | d.reyes@contoso.com; j.olsen@contoso.com |
| Count before | 2 |
| Recipients after | d.reyes@contoso.com |
| Count after | 1 |
| Verification | Confirmed by re-read |
Direct Assignments sheet
Optional. Direct permission grants to that person, if you asked for those too.
Errors sheet
Anything that could not be read or changed, with the reason.
What you need
- Write access to the libraries in scope.
- A Graph token, because sharing links live in Graph. A cookie-only sign-in cannot drive this, and the app says so rather than reporting nothing found.
What it will not do
- Group access, inherited access, organisation-wide links and anonymous links are not touched. If the person can still reach a file through a group, this does not change that, and the report says which is which.
- The change is per link. There is no undo, though re-sharing with that person restores their access.
- Report shared links, on the Reports menu, is the read-only look at the same data.