cancel
Showing results for 
Search instead for 
Did you mean: 

Allow run-only users for non-button flows (thus not requiring owner creds)

(Original title: Multiple users should be able to run a flow (not only owners))

 

Currently only the owners of a flow are able to run it, this is a huge this advantage, this means only the people that is creating and modifying the flow are the only people that is able to use it.

 

I'm aware about the sharing option for the button triggered flows, however, I'm talking about all the other triggers, the ones that work based certain thing changing or something new being added to the platform, the kind of things are actually worthy to automate.

 

Image a simple scenario, there is a SharePoint Library where an approval process must run when any internal user with access to the library creates a new document, surprinsily, even that users have the proper license for MS Flows, the flow is not triggered, only the flows owners are able to run it.

 

For sure the previous example can handled by using the classic workflows, however, this is about of evolving, taking advantage of new technologies and opening the door for new possibilities.

 

I don't understand why this extremely elementary functionality was not included in the first place.

Status: Planned

As covered in the comment, we currently have this functionality for button triggered flows, as well as for a selected item. However, for flows that run in the background they must run in the context of someones account. It doesn't actually have to be the owner's account, but the account can not be dynamically selected at runtime (e.g., if Fred uploads a file, the flow cannot run in the context of Fred since he has not granted consent to Flow to use his authorization context). That being said, this is something that we are now planning on improving in the future.

Comments
Anonymous
Not applicable

I wanted to respond to Stephen's comment -- because it sounds like there still may be some confusion as to what we're asksing for.

 

I think most of us recognize the fact that a flow has to be run in a context.  In my mind, what I'd like to see is the ability to define a flow (at an Admin level) and then push that flow accross a group of accounts by a rule such that the flow would be added just as if the owner of the account had added it to their account -- hence, a context in which to operate.  IOW, the original flow created by the Admin would be a sort of template that defines the actions to be taken but the actual flow created on each account would operate within the context of the account on which it is created.

 

Also, you mentioned in your example that the flow could not operate in the context of Fred because Fred had not given permission yet -- and I think that is where the rub lies.  In a corporate envirionment in which the accounts all belong to the Corporation (i.e. employees), the organization should have the right to push a flow as part of corporate policy as opposed to each user/employee being required to approve the Flow.  We as the organization don't have to request approval from the user when we set up rules to move them around in different security groups -- and we would view these Admin level flows similarly -- something enforced at the corporate level that gets applied to every user. 

 

Kudo Kingpin

@Stephen, any news when the additional functionality will be available?

Also any change that the team could share and the power user community (or a selected sub group) could input on the design?

 

by the way fully agree with @Anonymous

Power Automate

@ErichH - this is planned but I cannot share any specific timelines yet. Once the idea is marked as Started we will be able to provide more details on when it can be delivered.

 

Additionally, regarding @Anonymous's comment - I agree that an organizational account is owned by the organization, not each end user, but the reason we are taking this approach is because Azure AD and Microsoft Graph APIs have strict security policies that we can't physically violate (even if we wanted to). 

 

To add a little more detail, imagine you had a setup like this:

Rodd (IT guy) -> has access to -> Rodd's Mailbox 

John (employee) -> has access to -> John's Mailbox

 

Rodd and John, today, can easily set up Flows that have access their respective mailboxes. The way this works is they consent (via AAD) for these flows to use their respective AAD tokens to access the mailboxes they have access to. E.g.:

 

Rodd -> grants Flow#1 Rodd's AAD token -> which has access to -> Rodd's Mailbox

John -> grants Flow #2 John's AAD token -> which has access to -> John's Mailbox

 

Now, I believe the scenario you're trying to do is for Rodd to set up Flow #2 on John's behalf. The feature that we are tracking as part of this idea, is Rodd being able to create Flow #2. However, Flow #2, without a gesture from John, can not have access to John's AAD token. So what we are planning on doing is, rather than requiring John to go through an elaborate setup to create Flow #2, he can just "enable" it - which really means, granting it his token.

 

However, Rodd, cannot just get John's AAD token - this isn't a Flow limitation, this is a base AAD security infra requirement. What I believe you're asking for is this:

 

Rodd -> grants Flow#1 Rodd's AAD token -> which has access to -> Rodd's Mailbox

Rodd -> grants Flow #2 John's AAD token -> which has access to -> John's Mailbox

 

But this isn't possible because Rodd never has access to John's AAD token (per AAD requirements). Thus there is no way for Rodd to set up a flow without any involvement from John.

 

That being said, there is another approach, which actually is already possible today (if you're willing to call APIs directly), for this scenario. Instead of having John do anything, you could grant Rodd access to John's Mailbox.

 

Rodd -> grants Flow#1 Rodd's AAD token -> which has access to -> Rodd's Mailbox

Rodd -> grants Flow #2 Rodd's AAD token -> which has access to -> John's Mailbox

 

You can read about getting access to other user's mailboxes here. Once you do that, Rodd can then build however many Flows he wants that have full access to John's data. In reality, you wouldn't ever use "Rodd's" account, but likely create a system account that you grant access to (since you, Rodd, don't actually want to see John's email when you open Outlook). 

 

As I said, this approach is actually independent of this feature - and is already possible. The feature we're looking at building is to enable IT to distribute flows to other users without those users having to create the flow itself. However, each user still has to grant access to the Flow since it'll then user that user's AAD token. 

 

Please let us know if this makes sense. Also, it would be very helpful to understand if this feature that we're building wouldn't be useful given you don't want users to enable/disable on their own.

 

Kudo Kingpin

Hello @Stephen, thanks for your reply.

 

Thanks for your elaborate answer, we appreciate the time you took to outline some of the technical background.

 

let me out the core of the request as I see it.

 

Provide for the capability that experts write the flow logic and then share them with other users in run only mode. The user should by able to leverage the flow without the ability to change it, after the user acknowledged the change in relevant connectors. today this is possible for mobile button triggered flows. Tomorrow this should possible e.g. for http requests etc.

 

it should remain the choice of the owner with connector credentials should by used, with exception to manipulating emails. Thus has to be done under the run only user connectors.

 

hope this helps 

Power Automate

Thanks @ErichH - that's great confirmation. What you describe is exactly what we are trying to build. I just wanted to call out that by "leverage" that means the other users *can* use the flow (without being able to change it), not, that they *must* use that flow (without their consent).

Advocate I

Hi all,

I've opened a closely related, but simpler flow idea - Sharepoint Flow Button Should NOT require Edit or Write permissions.

This might help out some of you - please Vote!

Regards

 

Kudo Kingpin

I have now written a workaround via a HTTP - Request.

Requires individual "send Email on Response" flows, their distribution and respective individual URIs to be kept in a central list.

has the option to ask sender for "Yes - OK to SEND" or "No - STOP"

 

GEN005.PNG

 

 

 

New Member

Hi, what's the update on this please? I created a flow that is triggered by clicking a button (for a selected item) and only owners are able to run it. I dont want to make everyone an owner. Has this issue been fixed? I'd like any one with permissions to the library to be able to click on the button and for the flow to run.

 

Thank you

Anonymous
Not applicable

Hi,

 

any update to this?

 

I have to publicate a Teams message when a record is created on Dynamics 365, but this message have to have as author the the user that had created record on Dynamics 365 (now the message have the user of connection to teams as author).

This method run very well when in the flow there is a manual trigger, but in this case I don't have this requirement

 

Thanks

Sergio

 

New Member

Nice job guys, you forgot the basic trigger function.