Re: Flow inside managed solution cannot be shared ...

Anonymous · ‎07-30-2020

I have a Flow inside a managed solution that is an instant flow. It get triggered manually by a selected file inside a SharePoint document library (Approval Workflow).

I deployed the solution to the customer and re-configured the actions to point to the right libraries and approval actions etc.

For the users to be able to start the Flow I wanted to add the SharePoint list (library) where the Flow is attached to to the run-only users. So in the Flow "Dashboard" in the "Run-Only Users" section I wanted to click on "SharePoint" and select the site and library, but there is no "SharePoint" option available. I see only the option to invite users or teams directly.

I then created a test Flow inside the customer tenant, with the same type (instant flow for selected item/file) and added it to the same library. When I open up "Run-Only Users" section of this flow, I see the "SharePoint" option there.

So, my question is. Is this a bug or a normal behaviour? Can Flows of managed solution (and unmanaged?) not be shared with SharePoint lists?

I read in another post that a user had a similar issue and it worked for him suddenly and that the Power Automate Platform has issues with flows not directly created but coming from a solution - is this still true and I have to wait... some days (which would be not very cool)?

zylantha2 · ‎01-07-2021

I have the same issue, in that the options for run-only permissions for a flow stored in a Solution are different from those in "My Flows" - and broken.

For a flow in "My Flows", if it is triggered "For a specific (SharePoint) Item", then you have the option to grant run-only permissions to the users of that SharePoint Site, thus:

There is a specific tab for sharing with "SharePoint" - and in this case I've shared this particular flow with all users of the "Contracting" sharepoint site (which is a team site).

However if you create the flow in a Solution (for example, so you can call child flows), the "Run-only permissions" dialog is different:

It purports to allow you to invite "teams", but has no tab to add permissions linked to SharePoint.

In addition if you try to add a team, it errors out (even though it claims you can add a team):

You also cannot grant the run-only permissions to groups (such as "Everyone") - so this is basically broken. I would have to add every single person in the organisation manually to be able to grant them run access to the flow (which is just crazy).

A similar question (also unanswered) has been posted here:

https://powerusers.microsoft.com/t5/Building-Flows/Sharing-Flows-in-quot-Solutions-quot/td-p/539596

Broesmeli · ‎06-22-2021

Same issue here. I want my manually triggered workflows inside a solution to be available for everyone in the company (over 1000 user) and I don't manage to add them as run-only user 😞

Any news here?

WConsulting · ‎09-20-2021

Any update to this one? Migrating a lot of flows for a customer here and now have to tell them that some flows can't be inside of a solution. But should be under the 'my flows' to share them with a security group, which is very messy to get a lot of flows under 'my flows'. Any input from Microsoft here?

Clos · ‎10-01-2021

I believe I have a solution for this, which I must have found some information on before, trawling through forums. It works in my environment so I hope it would work in yours too.

Although you can't add groups or lists as a run only user to a flow in a solution, you can add business unit teams. You can set these teams up to point to an Azure AD security group, so anyone in this group should be able to run the workflow.

Before setting up the business unit team, you'll need to create a security group in Azure AD and get the Object Id on the overview page, as you'll need this when setting up the team.

To set up the business unit team go to the Powerapps admin center > Environments > Settings for your environment > Users + permissions > Business units > Your business unit (you might have to create one?) > Teams > New Team button

In the new team window, give it a name, select the correct business unit and an Administrator. You then need to change the Team Type to: AAD Security Group and set the Azure AD Object Id for a group to your groups Object Id. The membership type should be Members and guests. Save and close the team, then it should be available when you go to set a run only user. For some reason the teams take a long time to populate, so if you have a lot of users it could take a while.

Hopefully this information is clear and you can follow it, and it works for you. I did a few of the steps a long time ago so can't actually remember if there were extra steps I had to take at the time.

MicaelLev · ‎10-06-2021

@Clos I have doubts this will work, since Dataverse Teams are only populated when user from AAD groups log into Dataverse! Login in Sharepoint would not do this... Can anybody confirm?

Clos · ‎10-13-2021

@MicaelLev Thanks for the information. So to support my post, I created a new group at the time which has slowly been filling up (I admit I'm not sure how, as far as I'm aware my users aren't logging in to the Dataverse directly).

I have been able to test the permissions using this team though and it does enable/disable the ability for my users to run the workflows in the solution based on the team being a run only user. If the team is not a run only user, they just don't see the workflow in the list.

MicaelLev · ‎10-13-2021

@Clos oh cool thanks for confirming that it does work! We will also try it out within our environment. As a last question, no need for Dataverse licences with your users inside the team?

Clos · ‎10-13-2021

@MicaelLev I'll be interested in the outcome! The users have a mix between O365 E1 and M365 E3 licenses and no specific Dataverse licensing yet.

Lawrenceharvey · ‎02-17-2022

Hi, did you manage to get this to work? I can't seem to get it to. Any information would be really helpful.

Lawrenceharvey · ‎02-18-2022

An update on this one.

Been able to get this to work. Our environment is secured by a security group. Our new team assigned AAD group needed to be added as a nested group to one controlling the environment. The team also needed to be given the basic user security role.

Additionally users needed to access a dataverse URL before they could use the SharePoint button (in our case). We used the flow URL in the solution for them to visit.

After this the resource was available to the user.

zylantha2 · ‎03-22-2022

I can also confirm that the original suggestion by @Clos is correct. In order to create the business unit team you need to be an administrator (so much for this being a citizen developer platform), but once done, "All Users" is available to add as a run-only user, and this seems to work great.

MicaelLev · ‎03-22-2022

Se have a conclusion from our tests. All of the above is true, but only in the default environment maker. If you use any other environment, the flow will never ever ever ever ever appear. For nobody, not even the owner. As we use solutions with different environments to be able to test before production, this is a pain. What we had to do is json format the SharePoint lists and adding the flow call with his envID/flowid.

This shows the button to everybody, but people without authorization get a blank flow panel....

PabloD · ‎06-02-2022

Good lord... Good solution, but with such a limited applicability...

We have flows that have child flows so we HAVE to add them to a solution, but now we have to do backflips to expose them to users and even with that we cannot use a proper development/production environment.

Every time I feel that PowerAutomate is "finally there", we find another roadblock. This is getting old, Microsoft.

zylantha2 · ‎06-02-2022

It's all about par for the course really, with Power Automate.

It's even worse when you have a flow that wasn't in a solution, and need to add it into a solution so it can be called as a child flow, or call other child flows, then find out:

Once imported into a solution and have a child flow call, there is no way to export it back out, or duplicate it.
Your trigger action is broken and you therefore have to rebuild the entire workflow (that's like saying you have a flat tyre, so you need to go and buy a new car ...)
You have one action (or many actions!) in the flow that prevents it from being called as a child flow (this is a huge one and almost impossible to fix) - so you can't call it as a child flow, you have to turn it into a HTTP triggered flow, which you could have done in the first place outside of the solution. Or you could go and rebuild it from scratch again (see above ... buying a new car because your tyres are last year's model)

MicaelLev · ‎06-02-2022

Hi zylantha, there is a fallback to this problem. If requires to be confortable with editing directly json definitions.

If the flow is fairly big, create a new blank flow with all the connector types so all the references are inside this flow. Export your solution ans unzip it. Open it with vscode and find your first broken flow. Copy the core definition and replace the New flow with this part. Make sure that references all match. Rezip, and import again. If you have worked well, your new flow will be now a New converted solution flow and you can remove the first one.

zylantha2 · ‎06-02-2022

Ok, so to fix the flat tyre, you first remove the engine, radiator, and the seats, disassemble the dashboard, then undo the lug nuts, take the tyre off the rim, before putting it back on, reinflating the tyre, and reassembling the rest of the car. Piece of cake!

I love low code tyre changing, this means anybody can write their own automation scripts without ever touching a line of code.

MicaelLev · ‎06-02-2022

Thats why i still have a job!

zylantha2 · ‎06-02-2022

Not only that, but it takes you 10x as long to create or update anything in Power Automate than it would do in any other programming language, so you get to charge 10x as much! What a cunning plan!

MicaelLev · ‎06-03-2022

I mean, it's only Microsoft who says it is citizen developper, not me! 😛 And as a real example, we did a powerApps project that we came first with a quote that custom development would be more suited to the client. But Microsoft convinced them that it did not require developpers. It finished with 5x over budget and needing 2 developpers since nobody knew how to...