PowerCUT #1 – Button Flows don’t trigger for shared users after deployment

Have you ever encountered an issue where you’ve deployed a Power Apps solution to a test or production environment as managed, and you’ve got some button flows (Power Apps) that perhaps work for you, but don’t even trigger for shared users? In this first… READ MORE [https://lewisdoes.dev/blog/po
road landscape art street
Photo by Jose Antonio Gallego Vázquez on Pexels.com
In: Low Code Lewis Content 🚀

Have you ever encountered an issue where you’ve deployed a Power Apps solution to a test or production environment as managed, and you’ve got some button flows (Power Apps) that perhaps work for you, but don’t even trigger for shared users?

In this first PowerCUT post as part of my new series where I share the fix to issues I encounter in my development, I’m going to show you how to fix this issue if you’ve come across it yourself!

Power Platform Admin Centre

First we need to go the Power Platform Admin Centre, to get access to our target environments configuration. Go to admin.powerplatform.microsoft.com to access the admin centre. Then select environments in the left hand navigation, and finally select the environment you’ve deployed your solution to, where you’re having this issue.

So… what is the issue here, the issue we’re most likely having, is that we’re missing some permissions that let us read the flows we’ve deployed which means they won’t even trigger if we click the buttons or carry out the actions that should make them run!

Editing a security role

So, in order to fix this issue, we’re going to need to add some permissions to the security role we’re assigning our end users. Chances are, you’re just assigning the ‘basic user’ security role, especially if you’re not delivering a Dataverse solution, but still need the permissions to make things like flows run 😉

Go ahead and click ‘see all’ under security roles in the access box of this page. Next you’ll want to select the ‘Basic User’ security role, click the three dots against it to see more actions and click ‘edit’.

Once you’ve clicked ‘edit’, the security role should open up in a new window or tab. This will now let you edit the permissions against all of the tables in your environment for that security role.

To add the permissions we need, click the ‘Customization’ tab. Then for the ‘Process’ table set the ‘read’ permissions to ‘Organization’.

Now, simply ensure that your users have that security role assigned as the minimum if they should be able to trigger button flows, and that should fix your issue!

Custom Role?

Are you working with a custom role that you’ve created for your solution and you’re perhaps not using the out the box ‘basic user’ security role? Perhaps you’ve taken a copy of the basic user role to add additional custom entities to?

In this case, make sure you make your edit in your development environment before you deploy to test, UAT, production etc to make your fix!

You might even do this with your basic user security role in development, add it to your solution, then roll it out. However, if you want to take this approach, I wouldn’t add the security role into an existing project solution, as you’ll most likely need this fix for the majority of solutions you develop. Instead, add it to a new solution (perhaps name it Edited Security Roles or something like that) and then make your change in development and deploy that! This way you’ll keep your security role working in your target environments regardless of whether or not your project based solution / developed solution is still installed in that environment. You also won’t have to ensure you add the security role to every solution you develop 🙂

If you have any questions or comments on this PowerCUT then let me know down below!

Written by
Lewis Baybutt
Microsoft Business Applications MVP • Power Platform Consultant • Blogger • Community Contributor • #CommunityRocks • #SharingIsCaring
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to LewisDoesDev.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.