PowerShell : Get-AdminFlow does not return the flow definition...

[spplante]

Hi there,

We did a PowerShell script to extract informations of all flows accross an environment in order to be able to monitor stuff that are not available in the OOTB audit. We used the PowerApps admin cmdlets in order to get everything we could on the Flows/PowerApps and everything works as expected except one really annoying thing, which in my opinion is clearly a bug :

The Get-AdminFlow command does NOT return the Flow's "Definition" property, only the "DefinitionSummary" property which is totally useless, because for example I can see a "SendMail" action is used but I can't see where the email is sent etc...

There is multiple articles saying that in order to get the full definition, you have to :

- Set the current user as a Flow owner

- Run the "Get-Flow" command which does return de "Definition" property (while Get-AdminFlow doesn't, go figure)

- Then remove the current user as a Flow owner

This sounds like a great solution, however what these articles fail to talk about is the fact that by doing this, ALL personnal Flows of the company will move from "My Flows" to "Team Flows" for every single user, which is really confusing for users. You would think that removing the service account from the owners after getting the definition would solve the problem, but no, this is a documented issue, once a Flow becomes a "Team Flow" (because more than one owner), there is no way to bring it back to a regular Flow even though you leave only a single owner.

So unless this bug is fixed, there is no way the solution above is viable, which leaves administrators with no way to get a Flow's full definition.

Is there any plan to fix either the "Get-AdminFlow" command or the "Team Flows" issue? That would be really helpfull.

[pakefali]

Hello,

I'm sorry you're hitting this issue. Let me get this to the right people so they can respond here. 

Panos

[Hayes3d]

That is one of the things I have been trying to figure out for the past two weeks as well. I need not only the actions that the flow is performing, but details of the values inside specific actions. That way I can spit all of the data out, store it somewhere, leverage PowerBI to create a dashboard that we can drill into specific flows and see what people are doing to ensure they are not just forwarding email to their personal email accounts. (That is just one example)

[zaicnupagadi]

I've been thinking about the same, was about to create the powershell script, I'm so happy that I saw your post on forum! Saved a few days!

I've been recently on a call with Microsoft, man, at the beginning a guy did not understood what I am asking for and I was like "I can forward emails with flow outside of the company" and the guy was "yes you can do it" I mean I wrote in the ticket my concern and told that to him but it was just like talking to a rock or wall - he was explaining me what flows can do 😄 later I spoke to him like to 5 year old speaking very loud with 2 second pause between each word, and... he gave me the other guy and that guy suprisingly understood me in 5 seconds 🙂 and he told me they cannot do anything about it - product group knows about the issue (forwarding emails). He told me that we can use DLP to block using Outlook connectors with flows, after that they send me the link to basic DLP documentation and closed the case... hahahaha <- laugher through tears.

[Carsten_Growth]

Have you considere taking a look at this tip from Serge Luca
https://sergeluca.wordpress.com/2019/04/08/create-a-flow-that-finds-your-flow/

Download and import his flow to see his logic searching inside the definition of the flow

[Hayes3d]

Getting flows that a user has created is actually a very easy process, I have already built that into a PowerApp by getting all of the flows in an environment and using a filter for author, created date, modified date, is it shared with others users, etc. I can get all of that information, but none of it really tells me what is in the flow, what values/parameters that people are using.

If I need to find all flows that talk to a specific SharePoint site, I can't do that.
If my Exchange team wants to know everyone using flow and forwarding an email to a personal email, I can't do that.

If my boss wants to know all flows that use an HTTP request that leverages Graph API, I can't do that.

I don't want to block this stuff using DLP, but we want to know things without having to grant ourselves access to every flow (which changes it to a team flow) and manually opening them. 

[zaicnupagadi]

@Hayes3d 

Haha... I am so used to MS giving me answers to questions I haven't asked instead of answering my actual questions ^^

[Hayes3d]

@zaicnupagadi That's funny, I had that exact scenario today. Asking about a PowerApp shared with everyone, which also shares the SQL connector with everyone, so everyone can now create their own PowerApp using that connector. He started talking about licensing and everyone needs a P2. I replied, I think you are mistaken on that... (I knew he was, but I was trying to be nice). We already have standard licenses via E3 which allow this. P1 = premium connector, which SQL is standard. He just jumped to conclusions...

[zochi_7]

I think that you can get information of connectors by executing Get-AdminFlow command separately.

For example

$flows = Get-AdminFlow
foreach ($flow in $flows) {
    $detail = $flow | Get-AdminFlow
    $detail.Internal.properties.connectionReferences	# connector infomation
}

[zaicnupagadi]

Thanks for answer,

Unfortunately I got no such property.

Cheers,

J