Get-PnPFlow -- WARNING: This cmdlet is not available under application permissions

[renewtx]

Notice

Many bugs reported are actually related to the PnP Framework which is used behind the scenes. Consider carefully where to report an issue:

Reporting an Issue or Missing Feature

In one of our PowerShell scripts (which runs as an automated task) we connect using the following to establish a connection (using App Reg $clientId) and the connection works fine:

Connect-PnPOnline ($tenantName + ".sharepoint.com") -ClientId $clientId -Tenant ($tenantName + ".onmicrosoft.com") -CertificatePath $certPath -CertificatePassword (convertto-securestring -String "xxxxxxxxxxx" -AsPlainText -Force)

However, once connected we then attempt to use Get-PnPFLow to access the flow instances in the environment using

Get-PnPFlow -Environment $environmentName -SharingStatus Personal -Verbose

Expected behavior

For Get-PnPFlow to return a list of flows (which used to work BEFORE Sept 9th when the security change related to PnP came out which required us to set up the App Registrations). Best we can tell our App Reg is set up correctly and the Connect-PnPOnline call does create a valid connection via the App Reg.

Actual behavior

We get this error:

Getting flows from Flow Env: Default-yyyyyyy-xxxx-xxxx-xxxx-yyyyyyyyybec
WARNING: This cmdlet is not available under application permissions
Get-PnPFlow: C:\KEEPit\FlowMonitor\FlowMonitor.ps1:261
Line |
261 | … $flows = Get-PnPFlow -Environment $environmentName -SharingStatus …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Make sure you have granted access to Azure AD App to Interact with Power Platform, To help understand the
| required permissions visit
| https://pnp.github.io/powershell/articles/determinepermissions.html#help-i-cant-figure-out-which-permissions-i-need

We have granted the App Reg full access to manage all flows in the environment.

Is there another permission needed? I tried running using the verbose option as suggested in #4353, but all it shows is:

Get-PnPFlow: Make sure you have granted access to Azure AD App to Interact with Power Platform, To help understand the required permissions visit https://pnp.github.io/powershell/articles/determinepermissions.html#help-i-cant-figure-out-which-permissions-i-need

Steps to reproduce behavior

Stripped down version of our code that results in the same behavior
#===========================================================================

$environmentName = "" #NNConnect --Set the PowerAutomate environment
$tenantName = "" #NNConnect Tenant
$clientId = "" #NNConnect App/Client ID
$certPath = "C:\certs\PnP PowerShell Tasks.pfx"
$trgtUrl = ""

try{

Connect-PnPOnline ($tenantName + ".sharepoint.com") -ClientId $clientId -Tenant ($tenantName + ".onmicrosoft.com") -CertificatePath $certPath -CertificatePassword (convertto-securestring -String "password" -AsPlainText -Force)

$context = Get-PnPContext
$msg = ("`tConnected to: " + $context.Url)
write-host $msg

}catch [Exception]{

$msg = ("There was an error establishing connection to tenant " + "[" + $trgtUrl + "]")
write-host $msg
exit

}

#Get reference to all the flows in the PowerAutomate environment

$msg = ("==================================================================================")
write-host $msg
$msg = "Begin Processing ..."
write-host $msg

try{

write-host ("Getting flows from Flow Env: " + $environmentName)

$flows = Get-PnPFlow -Environment $environmentName -SharingStatus Personal #-AsAdmin

}catch{

$msg = ("`tThere was an error accessing the flow environment " + "[" + $environmentName + "]")
write-host $msg
exit

}

#Process the retrieved flows
$msg = ("Processing retrieved flows ... from env " + $environmentName + " (Found " + $flows.count + " flows)")
write-host $msg

foreach($flow in $flows){

#Grab the id and name for the flow
$id = $flow[0].Id -split "/"
$flowName = $flow[0].Properties.DisplayName
$flowId = $id[6]

$msg = ("Processing flow: " + $flowName)
write-host $msg

#Check for failed flows
$failedFlows = @()
$suspendStatus = ""
    
if(($flowName.StartsWith('KEEPit')) -and ($flow[0].Properties.State -ne "Succeeded")){

    if($flow[0].Properties.State -eq "Suspended"){

        $suspendStatus = $flow[0].Properties.FlowSuspensionReason
    }

    $msg = ("FlowName: " + $flowName + "; Flow ID: " + $flowId + "; Status = " + $flow[0].Properties.State + " [" + $suspendStatus + "]")
    write-host $msg

    $msg = ("`tFlow instance " + "`t`t`t`t`t`t`tFlow Status")
    write-host $msg

    #Grab properties for all the instances of the current flow
    $properties = Get-PnPFlowRun -Environment $environmentName -flow $id[6]

    #Check instance to see if it failed
    $failedCount = 0
    foreach($flowProp in $properties){

        #Get end time of flow
        $today = Get-Date
        $flowLastCheckDate = $previousTimeStamp   #Set last check date to previous day
        $flowLastRunDate = $flowProp.Properties.EndTime

        #Confirm flow was from last day
        if($flowLastRunDate -lt $flowLastCheckDate){

            #write-host "Flow was from before last check date"

        }else{

            #if flow failed then flag it
            if($flowProp.Properties.Status -ne "Succeeded"){

                $instId = $flowProp.ID -split "/"
                $failedFLow = ("`t" + $instId[8] + "`t`t`t"  + $flowProp.Properties.Status)
                $failedFlows += ("https://make.powerautomate.com/environments/" + $environmentName + "/flows/" + $flowId + "/runs/" + $instId[8] + "  [" + $flowProp.Properties.Status + "]" )
                $failedCount++
            }
        }
    }

}

}

exit
#===================================================================================

What is the version of the Cmdlet module you are running?

ModuleType Version PreRelease Name PSEdition ExportedCommands

---

Manifest 2.99.33 nightly PnP.PowerShell Desk {Add-PnPAdaptiveScopeProperty, Add-PnPE…

Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version PreRelease Name PSEdition ExportedCommands

---

Manifest 2.9.0 PnP.PowerShell Core {Add-PnPAdaptiveScopeProperty, Add-PnPE…
Manifest 2.4.0 PnP.PowerShell Desk {Add-PnPAdaptiveScopeProperty, Add-PnPE…
Manifest 1.12.0 PnP.PowerShell Core,Desk {Add-PnPAdaptiveScopeProperty, Add-PnPP…

Which operating system/environment are you running PnP PowerShell on?

• [X ] Windows
• Linux
• MacOS
• Azure Cloud Shell
• Azure Functions
• Other : please specify

[jackpoz]

Hi, in your case, you are connecting with a certificate, so only Application permissions will be used and Delegated permissions will be ignored. Use Connect-PnPOnline -Interactive -ApplicationId ... -Tenant ... to use Delegated permissions APIs.

[renewtx]

I am trying to do this as an application ... we are running this under a Task Scheduler task and so not as a user ... i.e. there is no user login that prompts for credentials. This was working before Sept when the security settings changed ... and I believe we have the app permissions set as needed ...

Am I doing something incorrectly?

Thanks

rene

[gautamdsheth]

@renewtx - as @jackpoz mentioned, you need to change the script to use interactive mode like this Connect-PnPOnline -Interactive -ClientId <ClientId>

Flow doesn't support application permissions, so certificate auth wont work.

[renewtx]

This used to work before the September change ... running this script as a task. So is this no longer supported?? All I am doing is interrogating the flow environment for the status of executing flows ...

Thanks

[jackpoz]

There's probably a lot of confusion here:

• As long as you authenticate with a certificate, "Delegated" permissions granted in Entra ID are never used. This didn't change in September, it has always been like this.
• The Enterprise Application that was removed on September affected only Delegated permissions, so authentication with an account, and not authentication with certificate
• There are ways to authenticate in unattended mode with service accounts, as long as MFA is disabled. This usually involves setting up Conditional Access Policies to minimize the risk and should be done after carefully reading Entra ID security documentation

Do you still have the script that worked until September ? It will probably show exactly what authentication method you used and explain why it worked.

[renewtx]

There definitely seems to be .. I know I am confused, and I've seen other posts elsewhere with users wondering.

In our original script we connected as follows:

$trgtSecurePwd = convertto-securestring -String "xxxxxxxxxxxx" -AsPlainText -Force
$trgtUserName = ""
$trgtCreds = new-object -typename System.Management.Automation.PSCredential -argumentlist $trgtUserName, $trgtSecurePwd
Connect-PnPOnline -Url $trgtUrl -Credentials $trgtCreds

That worked fine until September at which point our connections began to fail. We subsequently updated our code to conect as shown

Connect-PnPOnline ($tenantName + ".sharepoint.com") -ClientId $clientId -Tenant ($tenantName + ".onmicrosoft.com") -CertificatePath $certPath -CertificatePassword (convertto-securestring -String "password" -AsPlainText -Force)

The connection itself works and we get a context established (just like before), but now this call fails:

$flows = Get-PnPFlow -Environment $environmentName -SharingStatus Personal #-AsAdmin

The error we get is:

I tried using the -Verbose flag to get info about what permissions are missing but that did not provide any other details ...

Thanks

[jackpoz]

That helped a lot.
The way you need to connect is Connect-PnPOnline -Url $trgtUrl -Credentials $trgtCreds -ApplicationId $clientId -Tenant ($tenantName + ".onmicrosoft.com") , so the same as before plus the -ApplicationId $clientId -Tenant ($tenantName + ".onmicrosoft.com") part.

That's the change that happened in September, -ClientId (or -ApplicationId) parameter is mandatory even when using -Credentials.

You will need to add permissions of type Delegated to your application registrations to do everything that your script needs to do (SharePoint, Graph, etc).