DEV Community: Jake Mannion

Advanced SharePoint Permission Actions with Power Automate

Jake Mannion — Tue, 20 Jan 2026 18:00:00 +0000

Setting and creating permissions with precision using HTTP flow actions

📅 Originally published May 26, 2022 - hamsandwich.dev

Background

SharePoint is known for its highly customizable permissions. That flexibility can have its perils, of course, but with the right approach (and for the right scenarios) it can be very effective.

Power Automate provides a few basic connector actions for working with SharePoint permissions:

Revoke access to an item
Create access links for an item

Not much for now, but fortunately the HTTP to SharePoint action opens up numerous other possibilities.

Familiar Methods, New Approach

SharePoint's REST API has a number of endpoints for managing permissions. Most methods can be re-used across different entities like sites, lists, items, etc.

If you've done on-premises SharePoint development, you may already be familiar with some of them.

The calls are simple - no payloads, headers or returns to process for most scenarios. The only tricky part can be finding the exact syntax, and there may be some data peculiarities to manage, depending on your scenario.

HTTP Action Examples

🔷 Getting the Principal ID of a Group

Type: GET

ℹ️ Note: Replace GROUP NAME with your target group name

_api/web/sitegroups/getbyname('GROUP NAME')/Id

🔷 Getting Principal IDs for All Groups

Type: GET

_api/web/sitegroups?$select=Title,ID

Results will be an array of all groups available on the site.

ℹ️ Note: You can find group IDs manually by clicking individual groups within Site Settings -> People and Groups and checking the address bar.

Cutting this corner won't save you much time, however. For most scenarios, it's better to fetch the value(s) at runtime.

🔷 Getting Principal ID for Specific User

Type: GET

There are a couple ways to do this. First, you might want to use a tool like SP Insider (pictured above) to get familiar with the SiteUsers data structure within your site.

Here are two sample queries - one for email, one for user name:

_api/Web/SiteUsers?$filter=Email eq 'Sample.Person@samplesite.com'

ℹ️ Note: The search terms are case sensitive!

_api/Web/SiteUsers?$filter=Title eq 'Sample Person'

You'll get a single-node array in the return, containing the user's ID value for that site.

🔷 Getting Principal IDs for All Users

Type: GET

ℹ️ You'll be getting a lot of data back with this one, potentially, so consider using select to narrow the return down to just the fields you need.

_api/Web/SiteUsers?$select=ID,Title,Email

There are some important limitations to consider here:

SiteUsers data is site-specific
A user's Principal ID on one site will be different from their Principal ID on another
The SiteUsers list will only contain records for users who have visited the site (or have been added via a few other methods).

There is an ensureUser method to explore, if you want to pursue this approach further.

🔷 Getting All List/Library GUIDs

Type: GET

I tend to work with GUIDs more than GetByTitle endpoints, so the examples on this page are tailored to that approach. Here's a quick way to get all list GUIDs on a site, in case you need it:

/_api/Web/Lists?&$select=Title, ID

🔷 Getting All Role Definitions

Type: GET

Each permission role in SharePoint (Full Control, Edit, etc.) has a specific ID associated with it. You'll need this value for some of the example calls below.

_api/web/roledefinitions

Results will be an array containing objects for each role definition.

🔷 Get Current Permissions on Item/Document

Type: GET

_api/web/lists/getbytitle('LIST NAME')/items(ITEM ID)/roleassignments

Will return an array of objects. Each PrincipalId will tell you who has permission to the item, but not the permission type.

Use an Apply to Each step to loop through the results and perform further actions.

🟩 Break Permission Inheritance on an Item or Document

Type: POST

_api/Web/Lists(guid'LIST GUID')/Items(12)/breakroleinheritance(copyRoleAssignments=true, clearSubscopes=true)

🟩 Restore Permission Inheritance on Item/Document

*Added August, 2024

Type: POST

💡 Tip of the cap to Tom Riha on this one, which I neglected to include when I first slapped this page together. Saved me a few minutes of head scratching tonight.

_api/Web/lists/getByTitle('YOUR-LIST-OR-LIBRARY-HERE')/items(ITEM-ID-HERE)/ResetRoleInheritance()

🔶 Remove Permissions from a List/Library

Type: DELETE

_api/Web/Lists(guid'LIST GUID')/RoleAssignments/GetByPrincipalId(5)

ℹ️ Note: Replace the principal ID value for the user/group you are targeting, and the GUID for your list or library.

🔶 Remove Permissions from an Item/Document

Type: DELETE

_api/Web/Lists(guid'LIST GUID')/Items(12)/RoleAssignments/GetByPrincipalId(5)

ℹ️ Note: Replace the the principal ID and list GUID values to suit your specific scenario

You don't need a specific role definition for this one - it will simply remove the target entity's permissions (whatever those may be) for the item.

🟩 Add Permissions to a List/Library

Type: POST

_api/Web/Lists(guid'LIST GUID')/RoleAssignments/addroleassignment(principalid=5,roledefid=1073741827)

ℹ️ Note: Replace the the principal ID, role definition and list GUID values to suit your specific scenario

Conclusion

That covers many of the more common permission management activities in SharePoint. You can extend this approach to cover lots of other scenarios, as well. 👍

Custom Logging in Power Automate

Jake Mannion — Mon, 19 Jan 2026 19:58:54 +0000

Easy, practical DIY approach using SharePoint Online lists

📅 Originally published January 1, 2025 - hamsandwich.dev

Examining Events, Errors and Outcomes

Handling errors gracefully within your flow logic is important. Fortunately, there is plenty of guidance to be found on the subject:

How can we investigate exceptions without wading through countless pages of flow run history?

If integrating with Azure Application Insights is not in scope and the information available within the Automation Center is not granular or specific enough, consider custom event logging.

Scenarios / Use Cases

🏭 Performing bulk content operations and a certain percentage of failures is expected
📆 Building a solution that involves chronological activities and events
🧺 Collecting flow errors in a centralized location, instead of relying on “push” notifications
🤖 Providing visibility to runs from higher environments or from a service account context
🖥 Displaying flow outcome data adjacent to the automation context (for SPO scenarios)

Log List Examples

Approval Event History

Scheduled Automation

Bulk Content Sync

Creating a Log or Event List

Columns

There’s no perfect recipe, but I usually include a column for each of these values:

Run outcome (success, error, warning, etc.)
Outcome details
Associated item title
Associated item ID
Flow run ID

Then, add additional columns for your specific logging scenario, as needed.

💡 Keep in mind, simplicity is the goal here. Use single-line text columns whenever possible - avoid choice fields or complex data types (lookup columns, etc.)

For ALM scenarios, you may find adding these helpful:

Flow name
Solution name
Environment

Configuration Tips

Disable search on the list (advanced settings) or restrict list permissions to only the relevant individuals/audiences
Index any columns that might be needed for sorting/filtering
Include a multi-line plain text column, if you’d like to store JSON output
Create view(s) and add custom column formatting, if that helps readability
Examine the list after log entries start to populate - you may think of another field or two worth capturing

Cloning an Existing List

Assuming custom logging proves useful, you may want to create more lists in the future. You can use an existing list as a template, to speed creation. Some options:

ShareGate migration tool
Use an existing list option in the SharePoint UI (under site contents)
Microsoft Lists

Adding Logging Actions

Once your list is ready, it’s time to add some flow logic. New log entries will be added using a Create Item action.

There are two general approaches for adding logging steps - both achieve the same result, but have different considerations.

Add to Existing Flow(s)

You can sprinkle logging actions within your existing flow logic, utilizing copy/paste.

Pros	Cons
Simple, fast approach	If the list schema changes, you may need to update (and find) all previously-added actions
No additional licensing cost	Cannot add additional actions later (like sending notifications) unless done manually
Can store complex data types, JSON
Uses existing SharePoint Online connection / reference (if present)

Create Standalone Logging Flow

Alternatively, you can create a separate flow (HTTP trigger or child solution flow) to store your logging steps:

Once created, invoke it from existing flow(s) as needed:

Pros	Cons
Much easier to extend later, if needed	Additional setup time and complexity
Can handle complex data types (HTTP trigger only)	Requires premium licensing (HTTP trigger only)
One logging flow can be shared by multiple solutions / flows	Need to collect and send parent workflow context
Option to run asynchronously - won’t hold up parent flow

💡 Don’t forget a Response action (for HTTP trigger flows) or Respond to Power Apps or Flow action (for child solution flows)

Other Notes

Consider disabling retry policies whenever a standalone logging flow gets invoked or a Create Item log action is called. You don’t want to hold up a parent flow run in the unlikely event that logging hits a snag.
For logging hierarchical flow outcomes, consider creating an entry for when the parent begins, ends, and every child iteration in between. Store a shared identifier (like parent flow run ID) to help group entries later.
Calculating overall flow run duration, error and success totals, etc. can add additional value to the last log entry for a given flow run. Don’t spend the time adding that logic unless the extra insight is worth it, however.
You can use the logging technique described on this page to store errors / exceptions only, or you can include successful outcomes and other event types, depending on the situation.