2

The central issue I keep coming up against is this: How can I separate the permissions of the user who triggered a flow and the flow itself?

In a PowerAutomate approval workflow, after a document is fully approved, a copy of it is moved to a separate library, 'Final'. This library's permissions are set to read-only, so that no one can upload anything to it that hasn't gone through the approval flow. However, this step fails every time because the flow initiator does not have adequate permissions to create a document in the 'Final' folder.

The flow is triggered via a button in PowerApps. Both the PowerAutomate workflow and PowerApp were created using a service account with all privileges.

Is there a way to 'bake-in' the permissions of the admin service account?

Update

As @Willman has noted, the connections are associated with the account that created the flow. Despite this, it seems as though this does not give the triggering user the same privileges to lists/libraries as the service account has. I have confirmed this by attempting to run my flow as the test user both without write-access to the library and with write-access. In the former case, it fails every time, indicating that the service account permission levels are definitely not being applied through the flow.

3
  • What type of Flow are you creating? Is it a Solution aware Flow? – motionpotion Mar 9 '20 at 15:35
  • It is a PowerApps trigger Team Flow. Would wrapping it in to a solution solve this? – Rekamanon Mar 9 '20 at 15:41
  • Apparently existing flows can't be migrated to a solution, so even if wrapping it in a solution does work it isn't a great fix for me. – Rekamanon Mar 9 '20 at 16:39
1

Yes. In fact, you probably already are in some fashion and do not realize it.

Unlike the older style SharePoint Designer Workflows, Flows in Power Automate do NOT automatically run under the context of the user that triggered it. Each action in your Flow that uses a service in SharePoint or other Office 365 service has to have a defined connection to that service. You probably didn't even notice, but the first time you added an action that connected to SharePoint, the screen probably briefly told you that the action required a configured connection, and probably started to prompt you for the credentials of the account to use for the connection. If you had chosen the option to "stay logged in" when you last logged in to Office 365, then that connection dialog in Power Automate probably automatically logged in as you and saved the connection under YOUR user context. And then every additional action you added to your Flow that also needed to connect to SharePoint probably also automatically used the previously auto-created connection.

Here is how you fix it to do what you want:

  • Create an account that you will dedicate to being used for Flows, and make sure it has the necessary permissions for the actions that you are going to perform.
  • Go to the Power Automate designer (https://flow.microsoft.com), then in the left-hand navigation choose "Data" and then "Connections". (see screenshot)

enter image description here

  • Then in the list of connections, find the one being used by your Flow, and clicking on the ellipses, choose "Switch Account" (see screenshot)

enter image description here

  • Now you are prompted to enter the credentials of the service account you want the connections to use.
  • Now that you have this account, the best way to use it going forward when you want to create new Flows with this account is to open a new browsing session (or incognito) and log into Power Automate with this account, then the UI helper that auto-creates connections will create them using this account.

Also note that if multiple users have edited the Flow and/or you have edited at different times with different accounts, you may have a mixture of user connections within your Flow because each action has its own separate connection configuration. For each action that requires a connection, you can click the ellipses in the upper-right corner of the action to see the available and selected connections (see screenshot). You will likely need to check every action connection individually if any appear to be connecting with the wrong account.

enter image description here

8
  • I developed the flows using a service account and all the connectors are to that account. However, I still have to grant individual users edit privileges to lists and libraries for flows that update/modify data. The service account has owner privileges on everything in the site, so clearly the flows are not running as the service account. – Rekamanon Mar 9 '20 at 16:37
  • Each action within your Flow could potentially be using different connections. I added to my answer how to check each action's connection individually. – willman Mar 9 '20 at 16:49
  • Each action does in fact have two connection options. Confusingly though, both options are for the same account. Any idea what that is about? – Rekamanon Mar 11 '20 at 13:07
  • Also, from what I am observing of the behavior, the flows do in fact run with the permission levels of whoever triggered the flow. I created the flow with 'service_account' that has full access and tested it with 'test_account' that has only read access. When run with these permissions from the test_account, the flow fails every time because it doesn't have write permission. Changing the test_account permissions to 'contribute' allows the flow to succeed, but the test_account should not have this level of permissions, except when running this flow! – Rekamanon Mar 12 '20 at 17:21
  • 1
    Apparently, that is the behavior of Flows triggered from PowerApps. It seems like a bug to me that it would ignore the saved/configured connections, but googling for "User Context triggered Flow from PowerApps", there are numerous references to the fact that a Flow triggered from PowerApps will ignore the connections and run as the PowerApp user. I would suggest trying this workaround which splits off the update action into a separate flow triggered from the first. – willman Mar 13 '20 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.