Run PowerApps/Flow as system account

[Anonymous]

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

[Anonymous]

We really need a possibility to let the PowerApp connect via a service account to the data backend (e. g. Sharepoint). Maybe a switch (either direct user connection or functional user connection) in the PowerApps-Connection pane? Starting with Sharepoint lists is easy, but as it was stated out before, currently the PowerApp asks the user to directly connect to Sharepoint. Using PowerApp as a middleware between user and data backend would be nice. You cannot (and you don't want) set the Sharepoint as granular that the users don't get access to the backend data. Regards, Thomas Windscheif

[ScienceDept]

I am 100% behind this idea too. Using powerapps to build a science quiz app for my students. Would like the app to be able to patch sharepoint lists without the users being able to directly access them.

[Anonymous]

Any chance of getting this in the near future? Now when we have at least basic way to attach files, this is the last thing which blocks me from moving my SPD wokrflows to PowerApps. To me connect to the database as a current user is pretty dumb way, especially in case of approval workflows...

[Audrie-MSFT]

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

[MasterOffice365]

I tend to agree with Audrie.

On any other application development toolset, more complex applications are designed with based upon a n-tier application architecture.

Should a developer of an app using PowerApps wish to abstract the presentation tier layer (being PowerApps) from any data layer for that matter, they should accordingly implement an application tier layer (aka middleware). PowerApps cannot be both the presentation tier layer as well as the application tier layer at the same time. The application tier layer capability is already provided in the form of Custom Connectors which enable developer to abstract the presentation tier layer from the application tier layers for apps if that is your requirement.

Equally whilst certain Connectors such as the SharePoint Connector support oAuth, the notion that you could hypothetically use a Flow running under a system account to circumvent users from say directly accessing lists in SharePoint is quite frankly absurd in my opinion at least.

When you share an app to other users that depend on a Flow, equally that Flow would then need to be shared with any users of the app. By sharing that Flow with other users, those users could by all accounts then consume those same Flows within their own apps. By example with reference the context in which the SharePoint Connection would have been created associated to a system account, users would thus be able to view or modify any items stored in the corresponding SharePoint list. From a SharePoint perspective there would equally be no way of differentiating which user had actually modified or deleted any given item in that list.

In my capacity as a MCSM on SharePoint, I fully appreciate the correlation between the concept of what an "Impersonation Step" was leveraged for in workflows created using SharePoint Designer, and the “desired” functionality you would like within a Flow. However with workflows implemented using SharePoint Designer, users were not able to instantiate those workflows themselves unless that workflow specifically enabled users to start a workflow directly from the SharePoint list view page.

If you are comparing what was possible previously within a workflow created in SharePoint Designer, you equally cannot state that the purpose of the impersonation step was to display items from a SharePoint list in order that the user not have direct access to the backend SharePoint lists. SharePoint Designer list workflows were triggered when an item in a list was either created or modified. Equally Flow can provide that same functionality whereby a Flow created in a “system-type” account context is automatically triggered when a SharePoint list item is either created or modified.

Accordingly, the requested “must have function” to separate application access from database access has always been possible by developing a Custom Connector for your app.

[NigelP]

Hi Audrie

You Say "In Flow, you can assign accounts on an the level of the "Action"s performed."

How do you do this ?

Thanks

Nigel

[NigelP]

@MasterOffice365

I would totally disagree with your asertion :-

"Equally whilst certain Connectors such as the SharePoint Connector support oAuth, the notion that you could hypothetically use a Flow running under a system account to circumvent users from say directly accessing lists in SharePoint is quite frankly absurd in my opinion at least.

When you share an app to other users that depend on a Flow, equally that Flow would then need to be shared with any users of the app. By sharing that Flow with other users, those users could by all accounts then consume those same Flows within their own apps. By example with reference the context in which the SharePoint Connection would have been created associated to a system account, users would thus be able to view or modify any items stored in the corresponding SharePoint list. From a SharePoint perspective there would equally be no way of differentiating which user had actually modified or deleted any given item in that list."

The problem is that PowerApps has built in Business Logic to stop the lists being corrupted when a user updates a list, which could be bypassed if the list is updated directly.  Therefore it is imperative that users should be prevented from updating lists directly, but should only be allowed to update the lists using PowerApps..

Regards

Nigel

[WPB]

What about creating a table (or SP List) of users with their rights and handling this in PowerApps? I'm doing this in many of my apps. Not ideal but it works and is easy to use. The biggest downside is you have to create the rights for each and everyone... In my case, i created an other app and gave the foreman accounts access to it so they can fill these rights fileds.

[MasterOffice365]

I do get your point @NigelP, and equally @WPB I too have implemented a similar pattern a number of times where I have created a table or List in SPO containing the users of the app with a column for their user role.

On occassion i have extended this same pattern further by adding a further column for module, or alternatively based on say business function.

For example:

A 'Finance' user can 'edit' rows linked to the "Finance" department, however only 'view' other rows. 

That said, there are many techniques you can use to further refine access based on security.

For example:

You could have a Flow that triggers when a row is inserted into a specific list that then breaks the default inherited permissions for that list item and assigns unique permissions for that list item based on the user's role (expanding further on the pattern of implementing a list to define user roles for the app).

Alternatively:

Leverage an intermediate 'staging' list, such that all users may have insert permissions on that list for new items. Then implement a Flow that triggers when a user saves a new record into that list that triggers running in the context of a "System" account, processes the business logic, and thereafter 'moves' that row to the ultimate final destination list for which users would perhaps then have only read / view permissions to. Using a pattern such as this one would then quite possibly be similar to what u previously may have effectively would be doing in SharePoint Designer workflow with an Impersonate step, and equally abstract the ultimate destination list from users (to some degree at least...).

[Anonymous]

PowerApps adoption will be severely limited until this is supported. It's a VERY common design pattern, and working around it with Custom Connectors and Rube Goldberg style Flow setups is just rediculous. Besides, if it's possible via workaround, why bother trying to prevent it? Why torture everyone trying to use the product?

Out of 5 requests I currently have for small apps, 4 of them would be perfect for Powerapps + SharePoint, but only with support for delegated access to SharePoint data.

Not supporting this is favoring a purest technical opinion over real business needs.