Any equivalent to SP2010's "Impersonation Step" in PowerApps/Flow?

[Chad_V_Kealey]

In our SP2010 environment, we have an "application" that allows users to self-register for trainings and workshops. This works by having two lists: (1) the "Sessions" list and (2) the "Signups" list.

The Sessions list contains each scheduled workshop or training event. It includes the title, date & time, location as well as number columns for "max capacity," "seats taken" and "seats available". The "Training" team has contribute permissions to this list; all other users have read permissions.

The Signups list contains the contact info (entered by the end users) and a lookup column to the Sessions list (filtered on an InfoPath form to show only those where "seats available" is greater than 0). All users have contribute permissions to this list (item level permissions is enabled so users can only seen and edit their own registrations).

When a user registers, a SPD 2010 workflow executes to update the number columns in the Sessions list. In order to do that, the "Update Item" actions run inside of an "Impersonation Step" (to run with the permissions of the workflow author). 

I'm currently in the planning stage of replicating this functionality with PowerApps & Flow. However, both of these tools use the permissions of the user executing the PowerApp or initiating the Flow. To make it work the way it did in 2010, I would need to give all users contribute permissions to both lists. This isn't an acceptable solution (end users cannot be able to create additional sessions or edit/delete existing ones). If there were a way in flow to have some action be performed with the permissions of the Flow Author, that would solve the issue. However, I'm not expecting that to happen.

Maybe I'm trying to do this the hard way and there's some new way to tackle the problem that I'm not seeing?

[#2]

I have not seen any support for the impersonate or update-list-row permissions.

The other problem I've found is owner stickiness. I create a flow as userX and then share the flow with userY. Now when userY runs the flow (which just sends an email), the email is delivered FROM userX. Huh? UserX created the flow, but userY initiated it. This doesn't seem right.

[#3]

@Stephen Siciliano can you help here? I'm also very interested on having official answer from the team

[#4]

I'm having the same dilemma, I also want to be able to have emails sent from Flow to come from the site and not from me, but it keeps saying I can't do that.

[#5]

It is possible to send an email from the Microsoft Flow system account. Likewise, if you are given delegate permissions in Exchange to send on behalf of another user, you can configure your flow to do that. Third, you can set up a Shared Mailbox in your tenant to send the email (if you don't want to use a person's email but also want the email to come from your tenant not from "Microsoft Flow"). I hope this helps!

[#6]

Stephen, we are talking here about how to act on behalf of a user in Flow...

[#7]

Stephen, how about the original question? Can a Flow be configured to use the permissions of the author as opposed to those of the user executing it?

If not, how would you approach the problem described in the original post? To summarize, I don't want to give users edit permission to a list, but want them to use a PowerApp/Flow to modify items in that list.

[#8]

Thanks Stephen,

Can you let me know what the flow system account is called so I can use it.

I am also still interested in how do impersonate as well as this is something that was very useful in SharePoint designer.

Cheers

Stephen

[#9]

@Chad_V_Kealey - Back to your original question there are two types of flows: 

1. Flows that run in background in response to events, like an item being added to SharePoint list. In this case the flow always runs with the connections that are defined by the authors of the flow. So you can define a connection that has permissions to update the list. This connection is used irrespective of the event that triggers the flow.

2. Flows that run manually based on the user clicking a button in the UI. In this case the Flow can run either in the user's context, OR in the connections defined by the Author. The Authors of the flow define which path is used.

As a result, yes, it should be possible to do what you need today.

@Deleted - You can use the Action called "Mail - Send email" - it's the Teal colored one. 

[#10]

There is a video on how to use REST API in Flow to set permissions within SPO

One way to do it shown here, https://www.youtube.com/watch?v=_-vvlPXv8rc Original source is here https://powerusers.microsoft.com/t5/Building-Flows/Set-item-level-permission-in-list-using-Flow/m-p/...

[#11]

@Stephen SicilianoRe #2, I am triggering a Flow from PowerApps, but there doesn't seem to be an option to specify in Flow or in PowerApps to make the Flow run in a specific context. How can this be done?

[#12]

Hello, When I was referring to the Manually invoked flows I meant using the "Flow button". This trigger can be used and start flows from inside of the Flow mobile app or the portal. This functionality doesn't actually work with the PowerApps app at this time.

[#13]

@Stephen Siciliano, can you comment on how the new ability to add SharePoint lists/libraries as Flow "Owners" impacts the execution context of the Flow (if at all)? 

Specifically, I understand (hopefully correctly) that adding a list/library as an Owner effectively uses that object as the permissioning mechanism. Users with Edit permission to the list/library can edit the Flow; users that have Contribute permission can add items to the list and the Flow is triggered, but it appears to still run in the context of the Flow Author (or last Editor?).

Ideally, it would be great if there were a way to specify the run context per connection or per action in all Flow types (e.g.: on item creation or modification) as you can in manually triggered Flows.

[#14]

Your understanding is correct. 

Unfortunately, for the second part (run in arbitrary context per action), this isn't something we support today but we'll consider it for the future.

[#15]

@Stephen Siciliano, so the only way to have control over whose credentials are used for the connections would be to use manually-triggered Flows? Are Flows initiated from a PowerApp (e.g.: via a "Submit for Approval" button) considered "manually-triggered"? 

[#16]

That's correct. At this time PowerApps triggered flows don't use the same capabilities as button flows (aka manually triggered).