cancel
Showing results for 
Search instead for 
Did you mean: 

Run PowerApps/Flow as system account

Hello,

 

I am now working on migration from workflows to PowerApps/Flows.

First issue we have faced are sharepoint attachmets.... which as I can see are finally in development.

 

But second issue is that most of our workflows run under system account, as we dont want users to have direct access to list, but we want them to access them only via PowerApps/Workflow/Flow.

 

In SharePoint it was easy, we just used "Impersonation Step" or App step...

 

Would it be possible to implement something similliar in PowerApps/Flows?

 

Ideally, it would be nice to be able to specify user roles in PowerApp and then specify in each element or at least window which role is able to use the element.

 

 

Honestly, we are being forced to throw away our workflows, but new solution is simply not able to replace it as it not contain basic funcionalities which were available in workflows...

 

This is must have function, as you really cant just give full access to everybody to everything you want to access in application. We need to separate application access, from database access.

 

Thank you very much

 

Best regards

Status: Under Review

With PowerApps all security is managed at the data source so that App Makers do not create security overrides within the app. In some cases, you can also share custom connectors to expand access to data from your apps.

 

The "impersonate user" capability in SharePoint Designer is similar to what is possible today using Microsoft Flow. In Flow, you can assign accounts on an the level of the "Action"s performed.

 

We will consider feasibility for something similar to what is possible in Flow using PowerApps. 

 

Thank you for your patience,

 

Audrie

Comments
Anonymous
Not applicable

I fully support the idea. I created a reporting app, where the line managers can see all reports from all members, but a team member can only see his own report. The current construct does not allow this. So all sensitve information that should not be shared with a wider team are out of question today. This is realy a big show stopper - IMHO

 

Please fix this as soon as possble.

Regular Visitor

@Audrie-MSFT 

The inability for PowerApps to leverage a system account when calling a Flow caused issues for us recently as well.  We utilize many Flows, running under the context of an admin account with elevated permissions and running on the user's behalf since the user doesn't have the rights necessary.  But we found out the hard way that when a PowerApp calls a Flow, it runs under that user's context.  This forced us to grant permissions to a SharePoint site that they don't need to see or touch as well as reconfigure the Flow into multiple flows with different triggers to overcome this deficiency in PowerApps.  Is there a timeframe when this will be a possibility?  Thanks.

New Member

This is frustrating.  It should not be so hard to implement such a common design pattern.  Please consider streamlining how patterns like this can be implemented.

Frequent Visitor

I just spent the last two days building a PowerApps form for a SharePoint list to handle work requests and automation, only to discover that 90% of the Flow I've created to handle the automation is going to be useless due to this limitation.

 

Please implement this request or something similar, as I now need to build some janky workarounds to make this work.

New Member

Can't agree more...having an option like this would be awesome!

New Member

It seems to be a problem with the connectors, not with Flow/PowerAutomate. Authenticating in AzureAD does support application-logins (using the application ID and a secret/certificate). This would be the correct way of dealing with connections to AzureAD-connected ressources (Dynamics / Common Data Service / SharePoint / etc.) in cases where you want to execute actions with higher/different privileges than the current user.

My scenario: when creating a new instance of an entity in CDS I need to create multiple other entity instances without giving any "real" person access to these instances. Currently I do this by sending created instances of that entity to an Azure Service Bus and executing an Azure Function with a Service Bus Trigger. This Azure Function has access to an Azure KeyVault containing the app-id/secret of an application user in Dynamics CRM that has the privileges needed to interact with the entities. This is far from "low-code" and contains a complexity that is not acceptable for business users. With a connector supporting app-ID/secret as credentials, this would be possible to be implemented 100% in flow - easy and trivial extension to the authentication of the CDS/Dynamics-connector with high value impact to the PowerPlatform.