What happens when you delete unique permissions in SharePoint?

The item, folder or library stops having its own permissions and inherits the parent's again. Anyone whose access came only from the unique permissions — people it was shared with, guests, groups added only there, sharing links — loses access. Anyone who also has access via the parent keeps it.

How do I see who has unique permissions on a SharePoint folder?

Folder → Manage access → Advanced shows the role assignments on that folder. To compare with the parent you need to open the parent's permissions too, then work out the difference by hand or with PowerShell.

Does reset inheritance remove sharing links?

Yes. Sharing links are implemented as unique permissions on the item; re-inheriting removes them and the links stop working.

Can I undo delete unique permissions in SharePoint?

Not with a single action. The previous grants are gone; you would have to re-share manually. That is why the list of who loses what should be exported before resetting.

Before you 'delete unique permissions' on a SharePoint library: who loses access, exactly

Resetting inheritance removes every grant that isn't on the parent — shares, guests, group additions, links. Microsoft's dialog says "you will lose unique permissions" and nothing more. Here is how to list the names first.

The library has 180 folders with their own permissions, accumulated over five years of Share clicks. Cleaning it up is the right thing to do. The dialog says: You are about to inherit permissions from the parent folder or document library. Any custom permissions will be lost. It does not say whose.

What "custom permissions" means in practice

When an item stops inheriting, SharePoint copies the parent's role assignments onto it and lets people change them. Over time the item's list drifts from the parent's. Resetting deletes the item's list and points it back at the parent. So the people who lose access are exactly:

Shared-with users — anyone added via Share → name, who is not on the parent.
Guests — external users are almost always added at item level; they are the first casualties.
Groups added only here — a project team granted on one folder.
Sharing links — every Anyone / People in your organisation / Specific people link on the item is a unique permission; all stop working.
Elevated access — someone who has Read on the parent and was given Edit on the folder drops back to Read. They do not lose access, they lose a level.

And the people who keep access are anyone whose access also comes through the parent — the site groups, the M365 group, a direct grant on the library.

Listing the difference for one folder

By hand: open the folder's permissions (Manage access → Advanced) and the library's, and compare. With groups and links involved it is not obvious which side someone is on.

With PnP you can at least see both lists side by side for one folder:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/Projects -Interactive

# the folder's own permissions
Get-PnPFolder -Url '/sites/Projects/Shared Documents/Client X' -Includes ListItemAllFields.RoleAssignments |
  Select-Object -ExpandProperty ListItemAllFields | Select-Object -ExpandProperty RoleAssignments |
  ForEach-Object { Get-PnPProperty -ClientObject $_ -Property Member | Select-Object Title, PrincipalType }

# the parent library's permissions
(Get-PnPList -Identity 'Documents' -Includes RoleAssignments).RoleAssignments |
  ForEach-Object { Get-PnPProperty -ClientObject $_ -Property Member | Select-Object Title, PrincipalType }

Everyone in the first list who is not in the second loses access. Working that out is still by eye, and three things make it wrong by eye: SharePoint groups have to be expanded to people on both sides; an M365 group or Entra security group on the parent cannot be expanded here at all (it needs Graph), so someone who looks like they lose access may keep it through that group; and Limited Access entries are noise. Getting the names right, for every folder, with the group cases resolved, is the whole job — and it is the part we built the tool for.

Doing it for 180 folders

Find them first:

Get-PnPListItem -List 'Documents' -PageSize 2000 -Fields FileRef |
  Where-Object { $_.FileSystemObjectType -eq 'Folder' -and (Get-PnPProperty -ClientObject $_ -Property HasUniqueRoleAssignments) } |
  ForEach-Object { $_['FileRef'] }

Then run the comparison per folder, collect the loses lists into one CSV, send it to the owner, get a yes, and only then reset:

# per folder, after approval
Set-PnPFolderPermission -List 'Documents' -Identity 'Client X' -InheritPermissions

The sequence matters: export → approve → reset. There is no undo.

What a tool should refuse to do

Reset before you have looked. Inheritance365 is built around that rule: it sweeps the library for every item with broken inheritance, simulates the reset per item — every name, guests listed first, group-derived access resolved where it can be and marked may keep via group where it cannot — and the execute button stays disabled until the simulation has been exported at least once. Then it resets and verifies each item afterwards. That friction is the product.