Giving read access to a flow?

[asfesrsgadgrehg]

We are deploying Power Platform solution in a CI/CD fashion using Azure DevOps and Power Platform Build Tools, which means the service principal deploying the solution becomes the owner of the flows/powerapps and there isn't any physical user owning the deployed artifacts.

So far this is exactly what we needed, but what about giving READ access to users so they can at least see the execution logs if flow fails in production? Right now in the UI you can basically be owner of a flow, or nothing, it doesn't look like you can give someone read access to the executions without being able to delete the entire flow hehe...

Is anyone aware of a way to give to give READ access to a flow, even if it implies using PowerShell or the Dataverse API?

Thanks! 

[da1vea]

Have a look at this link - hopefully this helps

https://powerusers.microsoft.com/t5/Using-Flows/MS-Flow-Read-Only-permission/m-p/798064#M20121 

[da1vea]

Also this link - run only user

https://subscription.packtpub.com/book/business-and-other/9781839213793/9/ch09lvl1sec34/sharing-a-fl...

[asfesrsgadgrehg]

Yeah my question is exactly the same as our first link, however there is no answer provided in the link.

Adding a co-owner is not giving a user read only it literally allows him to edit and even delete the entire flow, that's not an option.

Run-only users is only for triggering manual flows and does not give read access either.

So at the moment, there isn't a way to give a user access to a flow other than owner?!

[da1vea]

it doesn't look that way then if run only users is not fit for purpose

[Matthy79]

Hello @asfesrsgadgrehg 

It’s a very difficult topic and even Microsoft self doesn’t understand it. I created a ticket once for that (including read only access to data) because we have a need that even I shouldn’t be able to accidentally modify something just because I am in the wrong environment.

At first we thought that “Service reader” could be the role for that. During the ticket calls Microsoft decided that “Service reader” shouldn’t be used for users and they changed that to not being assignable. 😩

After a lot of other calls where Microsoft told me to change this and that (everything we already tried before) with the outcome that you can’t even see the flows or can see them including having access to do everything, Microsoft had no idea how this could be solved.

Long story short. We still have the need and we still have no solution.

I can’t remember exactly but I think it ended up like most of my tickets that they told me to create a feature request and me telling them that even the highest rated feature request (created 7 years ago) are still not solved because Microsoft chooses the new features in a very special way.

If someone ever reads this topic and has a solution, please share it.

[asfesrsgadgrehg]

Yeah same experience here, I did notice that the System Customizer role, or a copy of the System Customizer role, does give access to the flows logs.

So I am currently working on creating a custom security role by checking one-by-one every single "Read" privilege that the System Customizer role has, until I hit the one needed to make it work.

A security role wouldn't be the best solution as it would allow the person with the role to see the execution of all flows (could be privacy concerns with this) but it would at least be a workaround, will keep you posted if I pull it off.

We also have custom built Azure DevOps tasks leveraging the Dataverse API in order to apply permissions on Power Platform solutions, and I already tried giving a user "Read" access to a "workflow" entity directly through code, but all it does is put the user as a "Run only user". Giving "Read + Write" puts the user as a "Owner" so even by code it doesn't look like it's possible.

[da1vea]

@asfesrsgadgrehg 

Your other option is to build a PowerApp that can view flow runs and errors. Have a look at this link, hopefully this helps

https://sharepains.com/2023/03/09/high-volumes-flows-power-automate/#

[asfesrsgadgrehg]

Yeah that will give me the status of a particular run but won't let the user see the complete picture of the run to identify where exactly it failed, this is a must for me because most of the time a single error message is irrelevant you have to drilldown the execution in order to understand the error.

As for my mission to identify the exact privilege of the "System Customizer" role that gives access to the flow runs, I spent hours copying ALL read privileges to a blank role and no success, my custome role wasn't allowed to see flow runs even with pretty much every single privilege in read. Then I copied all write privileges and it started working, so I continued eleminating everything until I could find one and single privilege required to see flow runs:

prvWriteWorkflow

Unfortunetely it doesn't help me at all because this role gives access to edit the flow as well so it defeats the purpose. To me it makes no sense that "Write" is required to "read" a specific run, but since there is an "Edit" button in the run details page, the page probably checks for the write privilege knowing it will be needed to press that button...

I would expect and error when clicking the edit button instead, that way read would still allow you to see the run, but it looks like they purposely decided to check for write privilege on load of the page for some reason...