(ESTIMATION TIME: 3 MINUTES)
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.
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.
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.
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 🙂