With Power Automate, you can create Cloud Flows that can be manually ran from specific records in Dynamics 365. Very useful for on-demand processes or activities with no specific triggers. But when they suddenly disappear, it can be confusing, especially if it's only for a specific user while everybody else is happily going about their business.

Run a flow on a record

Quick bit of context for you... Creating a Power Automate Flow with the Dataverse trigger called "When a record is selected"...

Means that it will automatically show up under the "Flow" heading on the Command Bar of any record within that table specified in a Model App...

But when it's simply not there, where do you start?

Could it be permissions?

Like most of us seasoned Teams people, when something's wrong, we blame the network. I'm starting to see the parallel with the Power Platform world, if something's wrong, we blame permissions. Specifically "Security Roles" and "Privileges".

I've been down this road before, and trying to use admin.powerplatforms.microsoft.com > Environment > Settings > Security, and then flicking around under Users or Security Roles one by one is almost useless for troubleshooting stuff like this.

A handy tip would be to use the genius ability to connect to the Dataverse as if it were an SQL Server, this means you can run a query to check permissions in any way shape or form you need, all within SQL Server Management Studio.

It's a convoluted process to link it all up, but it goes a little something like this:

• systemuser - the table that contains the user
  • teammembership - joins the users with the teams they are a member of
    • team - the table that contains the teams
      • teamrole - joins the teams with the Security Roles assigned
        • role - the table that contains the Security Roles
          • roleprivilege - joins the role with the privileges and the depth
            • privilege - the table that contains the Privileges

DECLARE @PersonName NVARCHAR(MAX) = 'Person Name'

SELECT
  systemuser.fullname AS FullName,
  privilege.name AS PrivilegeName,
  roleprivileges.privilegedepthmask AS Depth,
  privilege.accessright AS AccessRight

FROM systemuser

INNER JOIN teammembership ON systemuser.systemuserid = teammembership.systemuserid
INNER JOIN team ON teammembership.teamid = team.teamid
INNER JOIN teamroles ON team.teamid = teamroles.teamid
INNER JOIN role ON teamroles.roleid = role.roleid
INNER JOIN roleprivileges ON role.roleid = roleprivileges.roleid
INNER JOIN privilege ON roleprivileges.privilegeid = privilege.privilegeid

WHERE
  systemuser.fullname LIKE @PersonName AND
  (
    privilege.name like 'prvReadWorkflow' OR
    privilege.name like 'prvAppendToWorkflow'
  )
    

GROUP BY
  systemuser.fullname,
  privilege.name,
  roleprivileges.privilegedepthmask,
  privilege.accessright

ORDER BY
  roleprivileges.privilegedepthmask DESC

Alas, no... it seems to all be in order, at least the the very minimal required permissions that I expected to exist,... do exist. And it's the same for people who can still see the Flow.

Where next? Could I have been wrong, should I start drafting an apology letter to all things Security Roles and Permissions related?

In at the deep end

Asking the person to press F12 to open the developer tools in their browser, select the Console tab, and scroll to the bottom while they open up the Flow menu on the record in Dynamics 365, showed this particular nugget of redness that instantly jumped out at me.

Ha, I knew it... silly security. Always trust your instinct! And more importantly, always blame permissions! 🔐

So it IS a permissions issue, but seemingly not anything to do with Security Roles... what else could it be?

Logical Thinking

Since this had worked previously for this person, it was initially a bit of a headscratcher moment. But it's not ONLY Security Roles that are used to give permissions to tables.

There's also the ability to Share individual records, but annoyingly the SQL interface to the Dataverse doesn't expose the RetrieveAccessOrigin or PrincipalObjectAccessSet that are used to store those privileges.

Although all is not lost, there is a Dataverse Web API URL that you can run from a browser:

https://orgname.api.crm.dynamics.com/api/data/v9.2/RetrieveAccessOrigin(ObjectId=<RECORD GUID>,LogicalName='<ENTITY NAME>',PrincipalId=<SYSTEM USER GUID>)

And it will return JSON that includes a Response attribute with either...

• "Access origin could not be found. Access does not come from POA table or object ownership."
• PrincipalId has direct poa access to object (RECORD GUID)

In this case the user HAD direct access (i.e., the record was shared with them).

If you hate JSON, then you can go to a Model App entitylist view of the workflow table.

https://orgname.crm.dynamics.com/main.aspx?pagetype=entitylist&etn=workflow

But then you'll have to clear out the default filter from any of the views, and search for the Flow by name, click the record, and then use the Check Access button and add the person's name to the User lookup box.

After removing the advanced filter, so that the view would include the ones with Modern Flow category, clicking on the offending Flow that was hiding gets you to the Check Access button.

On another user that could still see the Flow in their menu, it looked like this.

Notice that the 'Overall Access' has MORE permissions, than the one above, despite the AppendTo being listed in the Access table at the bottom equally for both people.

Why has adding a direct 'share' reduced the overall access the person has on the table and/or record? Is this even anything to do with the issue?

My World Was Falling Apart

Everything I have learnt about Security Roles and Privileges with Dataverse suggests that it's all cumulative, i.e., you can only ever give somebody more access, there is no concept of 'deny' to take anything away.

Regardless of this insanity, removing the direct access for the person...

Instantly resolved the issue, the Flow magically reappeared, and everybody went on with their day.

Thanks for reading! I hope that helps somebody out there one day.