Break & Reassign SharePoint Document Permissions with Power Automate

Managing document-level permissions in SharePoint can quickly become painful.

You inherit permissions you don’t want
Files get shared with “Everyone” or random users
Cleaning this up manually is slow, error-prone, and inconsistent

This is exactly where Power Automate can help.

In this blog, I’ll walk you through a simple but powerful flow that:

Iterates over documents in a library
Stops all existing sharing
Breaks inheritance
Reassigns the correct permissions in a controlled way

All in one bulk operation.

High-Level Flow Overview

At a high level, the flow does the following:

Manually trigger the process
Retrieve all files from a document library
Loop through each file
Remove existing sharing
Grant access to predefined users or groups

Here is the visual overview of the flow in Power Automate 👇

Step-by-Step Breakdown

Let’s go through the flow from top to bottom.

1. Manually Trigger a Flow

Action: Manually trigger a flow

This flow starts manually.
That is a deliberate design choice.

Why?

Permission changes are sensitive
You don’t want this running automatically by accident
It gives you full control over when permissions are reset

💡 Tip
You can extend this trigger later with inputs (library URL, group names, etc.) if you want to make it reusable across sites.

2. Get Files (Properties Only)

Action: Get files (properties only) – SharePoint

This action retrieves all files from a selected document library.

Important notes:

We only retrieve metadata, not file content
This keeps the flow fast and scalable
The output is a list of file items with IDs and paths

This step defines the scope of your permission change.

💡 Best practice
Always test this on a small library first.
Bulk permission changes are powerful — and irreversible without backups.

3. For Each File

Action: For each

Power Automate now loops through every file returned by the previous step.

Everything inside this loop runs once per document.

This design ensures:

Consistent permission handling per file
Isolation (one file failing doesn’t stop the entire process)
Easier troubleshooting

4. Stop Sharing an Item or a File

Action: Stop sharing an item or a file – SharePoint

This is a crucial step.

What it does:

Removes all existing sharing links
Removes ad-hoc access (copy links, direct shares, etc.)
Effectively “cleans” the file’s permission state

Why this matters:

You cannot reliably manage permissions if old shares still exist
This guarantees a clean starting point before assigning new access

⚠️ Important
This does not delete the file — only its sharing configuration.

5. Grant Access to an Item or a Folder (Multiple Times)

Actions:

Grant access to an item or a folder
Grant access to an item or a folder 1
Grant access to an item or a folder 2

This is where the new permissions are applied.

Each action:

Grants access to a specific user or group
Assigns a defined permission level (Read, Edit, etc.)

Why multiple actions?

Power Automate grants access per user/group per action
This makes permissions explicit and readable
It avoids hidden inheritance or accidental access

Example patterns:

Action 1 → Executive group (Read)
Action 2 → Document owners (Edit)
Action 3 → Compliance or audit group (Read)

💡 Tip
Use SharePoint groups, not individual users, wherever possible.
It keeps governance clean and maintainable.

What This Flow Does Not Do (By Design)

This flow intentionally:

Does not auto-trigger
Does not guess permissions
Does not rely on inheritance
Does not preserve existing sharing

That’s the point.

This is a reset-and-enforce pattern, not a “best effort” cleanup.

Governance & Security Considerations

Before using this flow in production, make sure:

The connection account has sufficient permissions
Only trusted users can run or edit the flow
You document when and why it is executed
You test on a non-production library first

Bulk permission changes are powerful — treat them like admin tools.

Final Thoughts

This flow is a great example of how Power Automate can enforce SharePoint governance without custom code.

Once you understand this pattern, you can easily extend it:

Add conditions (only specific file types)
Use metadata-driven permissions
Log changes to a SharePoint list
Turn this into a reusable admin tool

If you want, next we can:

Turn this into a template flow
Add error handling & logging
Convert this into a parameterized solution for multiple sites

Just say the word 👋