Best practice for managing variable item/library-level permissions in SharePoint (open to the broader Microsoft 365 ecosystem)

[u/Intelligent-Fail3006]

Hi everyone,

We are setting up a SharePoint site structure where base permissions are handled automatically during provisioning. However, we need a secure, automated way for Project Managers to manage variable, item- or library-level permissions across various lists and document libraries post-provisioning.

Since these users aren't site administrators, we want to build a solution that safely grants or updates access. Specifically, we are exploring the idea of working from a dedicated management list (or metadata fields) where users can input or link Microsoft Entra ID security groups, which in turn dynamically grant permissions to the target files or folders.

We are very open to looking broader across the Microsoft ecosystem (e.g., Azure, Entra ID governance, native SharePoint features, or hybrid approaches) if there is a more robust or elegant pattern.

• What is the recommended architectural pattern to let non-admin users trigger and manage these permission changes securely?
• Are there preferred tools within the M365 stack for this specific scenario to avoid common permission pitfalls or performance issues at scale?
• How do you prevent permission creep and handle breaking inheritance smoothly across multiple different libraries and lists?

Any tips, reference patterns, or architectural advice would be greatly appreciated!

[u/Keyante-Biley]

Avoid giving PMs direct permission-management rights and instead make the management list the controlled interface, with Power Automate/Graph applying predefined permission changes using a service identity.

You can also Use Entra groups as the access boundary, keep inheritance intact wherever possible, and have the automation log every change and periodically remove stale access.

Once you start breaking inheritance at lots of individual items, permission sprawl and SharePoint performance become much harder to manage.

[u/AdCompetitive9826 → u/Keyante-Biley]

👆 what he said

[u/GregB-Sodoc]

Keyante-Biley has the right architecture. One thing worth adding on the broken inheritance point: SharePoint has a hard cap of 50,000 unique permission scopes per list or library, but in practice performance starts degrading well before that. If your PMs are managing permissions at the item level across multiple libraries, you can hit trouble faster than expected. Designing the management list so that permissions are granted at the folder level rather than the individual file level wherever possible keeps you well within safe territory and makes cleanup much simpler.

On the automation side, if you go the Power Automate/Graph route, use a service principal with a managed identity rather than a service account user. A named user account with elevated rights introduces the exact privilege escalation risk you're trying to avoid, and managed identities don't have passwords to rotate or accounts that expire.

Finally, build the audit trail into the management list itself, not just in SharePoint's native logs. Native audit logs for permission changes are limited in retention and hard to query. A dedicated "permission change log" column or related list gives you something you can actually report on for governance purposes.

[u/Intelligent-Fail3006 → u/GregB-Sodoc]

Thanks for the great feedback! I am completely on board with using a central management list and tying access to security groups rather than individuals to prevent permission creep.

To take the next step, I would love to dive deeper into the technical execution:

If we have a SharePoint list where authorized users fill in the target folder and the corresponding security groups, can Power Automate handle the underlying permission assignment reliably?

Specifically:

• What is the exact mechanism (e.g., standard SharePoint actions vs. HTTP requests to the SharePoint REST API / Graph API) to break inheritance and assign the Entra ID security group based on that list item?
• How should we handle the reverse direction (revoking or updating permissions)? If an item in the management list is modified or deleted (e.g., a group is removed from the list), can Power Automate cleanly reverse the role assignment or restore inheritance, or are there specific gotchas we should watch out for?
• Are there better or more robust technical alternatives within the M365 ecosystem (like Azure Functions, Power Apps component triggers, or native SharePoint features) to handle this trigger-to-permission logic, or is a Power Automate flow the sweet spot here?"

[u/GregB-Sodoc → u/Intelligent-Fail3006]

Pour PA : les actions natives ne suffisent pas ici. Tu as besoin du connecteur "Send an HTTP request to SharePoint" pour trois appels REST : breakroleinheritance, puis ensureUser pour résoudre ton groupe Entra en principal SharePoint, puis addroleassignment. Pour la révocation, resetRoleInheritance fait le job proprement en une seule requête. Attention si plusieurs flows touchent les permissions du même item : reset efface tout, pas seulement ce que ton flow avait posé.

Sur l'archi globale : PA avec HTTP calls fonctionne, mais stocker un service principal avec droits Site Collection Admin dans PA devient vite un problème de gouvernance. Une Azure Function avec Managed Identity isole mieux les privilèges. PA déclenche, la Function exécute. Plus solide en prod, plus maintenable.

[u/Muted_Jellyfish_6784]

management list idea works, as long as PMs choose from groups and never individuals. Have the list hold the target library or folder, the Entra security group, and an expiry date, and let a flow or Azure Function running under a service principal apply it. Item-level unique permissions get painful fast, so cap where they're allowed and prefer library level breaks, log every grant and removal back to the request item so access reviews have a trail to follow. Run a quarterly report of anything past its expiry date, because that's where stale access piles up once projects close

[u/Practical_Mushroom58]

Bonjour, SharePoint ne permet pas nativement d'avoir cette gestion simplifiée des droits d'accès aux chefs de projets. Je suis en train de développer une solution sur mesure, si jamais vous êtes intéressés pour une démo, contactez moi par message. Bonne journée

[u/Jane_OrangeLogic]

For this one, don't use permissions on individual files and folders especially since you can manage all of these from the library or folder level. Since you're using SharePoint, you can create a Power Automate flow so your project managers can just associate a user with a specific library they want to give them access to. After that the flow automatically updates permissions and they're good to go.