There is absolutely no documentation on this key function that is prerequisite to getting any value out of Flows at the enterprise level. Really, Microsoft should provide this. But Microsoft seems determined to force everyone to pay for premium support by providing no documentation at all on its products.
If anyone has a document explaining the options for this and how to set a flow up for each option, I would appreciate you sharing it with me. I am specifically interested in understanding the whole notion of "inviting a sharepoint list or library", because I have no idea what that means. Alternatively, I need to better understand how to make a Flow available run-only for my general user community. I don't have access to create security groups so that really is not an option unless there is an OOTB security group that includes all users.
Do you want to learn how to create a flow with the run-only users?
Do you want to create a flow with your general user community as run only user?
Could you please share more details about your general user community?
Microsoft flow support to add a security group or the user of your orgnization to be owner or run only user currently,
You could refer to link below to learn how to add a run only user to a flow:
You could refer to link below to learn how to add a list as run only user :
As I said in a different post, communities are no substitute for proper documentation, and this is a perfect example. The first link points to an overly simplistic, half-baked explanation of how to add named users as run-only users of a flow. It neglects to explain any of the other options related to the screens that are used to do this.
The second link at least points to something that attempts to explain what Flows is supposed to allow when adding a SharePoint list as a run-only user. But it does not help me understand why it does not seem to work for me when I have added a list. It makes quick reference to the fact that the user needs to have read/write access to the SharePoint list. However, in SharePoint, there is no such privilege as read or write. There is only add, edit, view, and delete. So which combination of these equate to "read/write"?
So while both of these offer some help, neither comes close to really answering the question. And they are certainly not an adequate substitute for the documentation that Microsoft should provide itself, written by professional technical writers rather than amateur, good Samaritans with a blog.
@MikeU1, we're very much in the same situation as you. What I've learned is that the concept of "Run Only Users" only applies to "manually triggered" Flows. In particular, this means Flows initiated using a "Flow Button", and NOT those with a "for selected items" trigger (even thought those are "manually triggered"). This severely limits the usefulness of Flow in our environment.
What has worked for us is adding SharePoint lists/libraries as owners. Doing this causes the Flow to "inherit" (for lack of a better term) the permissions of the list. Users with Edit permission or higher can edit the Flow; those with Contribute (the closest equivalent to read/write/execute permissions) can initiate or execute the Flow. However, even in this case, the Flow is using the author's Connections. So, actions taken are attributed to the author of the Flow. This is similar to how Impersonation Steps worked in SharePoint Designer 2010. In some situations, this is acceptable, and even advantageous, but obviously it's not always ideal.
The biggest issue we've run into using this method is that when emails are sent (and we have a LOT of workflows that send emails), they are sent as the Flow Author. However, we've worked around this by setting the "Send As" property to an O365 Group address or Shared Mailbox to which the Author has "Send As" permissions. If nothing else, this disassociates the individual user from the email.
I've submitted a suggestion (I don't recall where at the moment) that Flow Authors should be able to set an action to run as the Author or the user executing the Flow. I think that would be provide the best overall flexibility for most purposes.
@MikeU1, Actually, the suggestion I made is here if you want to add your vote and maybe follow-up with some of your requirements or use cases: https://powerusers.microsoft.com/t5/Flow-Ideas/Flow-Credentials/idi-p/124581
I understand your fustration really as I am in the same boat. I have created custom connector to call PowerBI APIs and used them with manual flow button with dropdown list to select the Workspace and Dataset to refresh dataset from that group and it's working fine if Owner(s) run it.
However, the main reason to create the workflow was to allow Run-Only Usersto run the flow but unfortunately they can't see the workflow at all!! And so far I haven't found a documentation that helps me troubleshoot the issue.
Am I missing anything here? Is this the limitation of the flow? or this is a bug! Honestly, I don't know.
Completely agree aswell, I created a workflow "for a selected item".
I will try adding SharePoint to the owners group but this needs documentation as you look like a muppet trying to work it out.
Sorry, I completely forgot to get back on this but it did work after trying a couple of time.
One thing I observed is, sometime users see a message like "New button is available" before they click on it which later shows the actual button.
I really don't understand why there is not a documentation on this... we can find example but it doesn't explain how it really works...
Btw, here is my issue ; i have 3 flows initiated with "manually triggered". Connections are Office 365 Outlook and SharePoint. I want my user to be able to use this flow without modifying it so i put it in run-user only.
My user only use the owner's flow connection and can't use any of these 3 flows. I thought he would be able to use them from the sharepoint list but it's not working.
Learn how to create your own user groups today!
Check out the new Power Platform Community Connections gallery!
Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.