PowerApp and SharePoint Online permissions

Hey ShimKwan​ Invoking PowerShell is not necessarily a bad approach, but I would avoid having the Power App itself become responsible for privileged SharePoint permission management.

A better design is to use the Power App as the request and user interface layer, and move site provisioning and permission changes into a controlled automation layer such as Power Automate, Azure Automation, or another secured provisioning service.

For example:

Power App → Provisioning workflow → SharePoint site creation → Group membership/permissions → Logging and governance

For project sites, I would also avoid assigning permissions directly to individual project documents unless there is a specific business requirement. If the entire SharePoint site is dedicated to one project, access is usually easier to govern by managing users through the site's Microsoft 365 group, SharePoint groups, or appropriate Entra groups and allowing the libraries and documents to inherit those permissions.

Breaking permission inheritance at the individual file level can become difficult to administer as the number of projects and documents increases. SharePoint supports unique permission scopes, but Microsoft recommends minimizing them and using inheritance and groups wherever possible.

If PowerShell is required for provisioning capabilities that are not conveniently available through the standard Power Automate SharePoint connector, it can still be used. However, I would run it through a secured backend process rather than exposing administrative credentials or privileged operations through the Power App. The automation identity should follow least-privilege principles, and business-critical automation should not depend on an individual employee's account.

For an enterprise implementation, I would also consider:

Using separate Development, Test, and Production environments.

Keeping the app and flows inside solutions.

Using connection references and environment variables rather than hard-coded configuration.

Using an appropriate service principal or controlled automation identity for long-running administrative processes where supported.

Logging site creation, membership changes, permission changes, and provisioning failures.

Establishing a standard project-site template so permissions and governance settings are consistently applied.

Since Microsoft Purview is planned for the future, I would include sensitivity classification in the provisioning design now rather than adding it as an afterthought.

Sensitivity labels for Microsoft 365 groups and SharePoint sites can control settings such as site privacy, external sharing, and access from unmanaged devices. One important distinction is that applying a sensitivity label to the SharePoint site does not automatically apply that same label to every document stored in the site. Container-level protection and file-level information protection should therefore be planned separately.

So, I would not necessarily remove PowerShell simply because PowerShell is being used. I would change the architecture so that:

Power Apps handles the request, a secured automation layer performs the privileged provisioning, and SharePoint groups/inheritance provide the primary access-control model.

That provides a cleaner separation of responsibilities and makes the solution easier to secure, audit, maintain, and eventually integrate with Purview governance.