Menu Close

How to use Flow on elevated privileges in SharePoint Online


In this article I’ll show you what is elevated privileges, when you may need it and how to run a Microsoft Flow in elevated privilages in SharePoint Online.

Elevated Privileges

Back days, when I was a SharePoint on-premise developer, there was a code method named RunWithElevatedPrivileges() which allows to accomplishing an operation with a higher permissions. The same functionality was available in the SharePoint Designer for workflows under the name: “App Step”

Technically speaking: using RunWithElevatedPrivileges() method run code with Full Control rights despite of the permissions that come from the user context. It was possible due to executing code under the Application Pool Identity (System Account), which has Site Collection Administrator privileges on all Site Collection hosted by that Application Pool.

However In Microsoft Flow there is no such option of running flow with higher permissions. But this is not without a reason! Even though you may think the best way is to override user permissions just to accomplish one operation, a good practice is to improve your solution architecture first. But sometime you won’t have another choice. When it may happen?

When you may need to elevate user permissions?

Some time ago on polish Microsoft 365 User Group I saw following question: “Can I create / configure the flow to be run on elevated privileges for SharePoint Online?”.

First tendency of repliers were to discourage the author of doing so. But he had a good reason.

Case 1

The author tried to achieve a two-level approval. Everything setup on a list of requests and a status field on it. Users and approvers should only have read access on this list and the logic (status update) should be done seamlessly “under the hood”. So in this case, no matter from which list or platform (ie. PowerApps) you start the flow, it still run under user context…a user who shouldn’t have access to the list with requests.

To be honest, when I though for a seconds I’ve found next example when you may need to run flow with an elevated privileges.

Case 2

Imagine that your users need to submit a request or an order that is stored in a simple SharePoint list. But in the same time you want to submit a record anonymously that is HIDE USER CONTEXT.

Is it possible? Actually it is 🙂

Impersonating Microsoft Flow

Please note that from now on I’ll stop using “elevated privileges” or “elevated permissions” and use “Flow Impersonation” because it’s more coherent to what we will really do. We will not give the user higher permissions, we will use another account with a higher permissions instead.

To explain you the architecture I’m going to use the sample of another solutions of mine: Whistleblowing app. The architecture of that app is as followed:

  • PowerApp gets information from a user and pass to flow. On this stage everything is personalized in PowerApps and Flow. We know who send what.
  • Flow A pass over HTTP request data to a Flow B. This is the exact moment where we pass data that is essential for the business logic, lose all context information, and impersonate user.

Impersonation is possible because connectors in Flow triggered by HTTP request runs under the accounts which was used during configuration step.

The whole IKEA-alike instruction of setting this up you can find in below video 🙂

Related Posts


  1. Oscar

    Hello, thank you for posting this. I have implemented your solution but when calling the ‘’ function in power apps I get this error ‘flow.Run failed: Connection not configured for this service.’ If I add the user as owner of the flow everything works as expected, but of course I don’t want to give users Owner role in the flow. Any idea what I could be missing?


  2. Helvecio

    Congratulations for the article it was very good!

    I would like some help, you showed how to write a record, but how do I read a table and present multiple records in power apps using power automate with this same strategy?

      • Helvecio

        The idea is to maintain the anonymity of records in Sharepoint, we set it so that on Sharepoint only the user who created the record can see the record, thus preventing anyone from accessing the list directly or through an excel connection (for example)
        I will use the article you submitted, thanks for your help!

Leave a Reply

Your email address will not be published. Required fields are marked *