Fix: Power Platform scan returns 0 flows + 0 apps
If the Dependency Graph or the Power Platform Deep Assessment reports "BAP returned N environments but 0 flows + 0 apps across all of them", your service principal is missing tenant-wide admin API access. This is a one-time 5-minute fix.
What's happening
The Power Platform Administrator directory role on its own lets MigrationFox list environments but not their apps + flows — those endpoints additionally require the service principal to be registered with BAP as a tenant management app. The Power Apps portal shows the same apps just fine because it authenticates as your user, not as a service principal.
The fix — one PowerShell command
Run this as a Global Administrator from any machine with PowerShell 5.1+ or 7.x. It takes about 30 seconds. You only do this once per tenant, not per environment.
1. Install the module (first time only)
Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser -Force
If your tenant has an execution-policy restriction, you may need -AllowClobber or to run as Administrator. This module is published by Microsoft and is the same one the Power Platform CoE Starter Kit uses.
2. Sign in as a Global Administrator
Add-PowerAppsAccount
A browser window opens. Sign in with an account that has the Global Administrator directory role. The Power Platform Administrator role is not enough for this specific cmdlet — it needs Global Admin.
3. Register your service principal as a tenant management app
New-PowerAppManagementApp -ApplicationId <YOUR_CLIENT_ID>
Replace <YOUR_CLIENT_ID> with the Application (client) ID of the Azure AD app registration that MigrationFox authenticates with. You can find it in Credentials → select your SharePoint service-account credential → the Client ID field.
Heads up
This command does not return anything on success — silence is success. If it errors, it's almost always because the signed-in account isn't Global Admin. The Power Platform Administrator role does not have the rights to call this cmdlet.
4. Wait 2–3 minutes, then re-run the scan
BAP caches permission membership for a minute or two after registration. Re-run the Dependency Graph (or the Power Platform Deep Assessment) from the MigrationFox dashboard and you should now see real flow + app counts in each environment.
Verifying the registration worked
From the same PowerShell session:
Get-PowerAppManagementApp
You should see a row for your ApplicationId. If it's there but MigrationFox still reports 0 flows + 0 apps after a 5-minute wait, see the troubleshooting section below.
Why this registration is needed
Power Platform admin APIs (api.bap.microsoft.com and api.flow.microsoft.com) authorize calls in two layers:
- Directory role — the calling principal needs Power Platform Administrator or Global Administrator. MigrationFox already checks for this on credential setup.
- Tenant-app registration — service principals (app-only tokens) additionally need to be explicitly allowed to call tenant-wide admin endpoints. Human users don't need this extra step because they hit the APIs with delegated tokens tied to their user identity.
The New-PowerAppManagementApp cmdlet adds your service principal to the second list. It's the documented Microsoft pattern for any service-to-service Power Platform admin integration and is used by the Power Platform CoE Starter Kit, Microsoft Purview, and third-party governance tools.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
Add-PowerAppsAccount fails with "user is not a licensed Power Apps user" |
Global Admin account has no Power Apps license assigned. | Assign any Power Apps license (including the free "Power Apps for Office 365" that ships with most M365 SKUs) to the Global Admin account and retry. |
New-PowerAppManagementApp fails with "403 Forbidden" |
Signed-in account is Power Platform Admin but not Global Admin. | Sign out (Remove-PowerAppsAccount), sign back in as a Global Administrator, and retry. |
| Command succeeds but scans still report 0 flows/apps after 5 minutes | Wrong ApplicationId registered (common — easy to confuse tenant ID with client ID). | Re-check the Client ID in your MigrationFox credential against the ID you registered. Run Get-PowerAppManagementApp to confirm. If the registered ID doesn't match your credential, run New-PowerAppManagementApp again with the right ID. |
| Some environments return flows but others don't | A specific environment has a Customer-Managed Key, sovereign cloud, or explicit deny policy. | Not a MigrationFox-fixable case — check the environment's admin settings in the Power Platform Admin Center. The scan will still work for all other environments. |
Alternative: per-environment Environment Admin
If your tenant policy does not allow New-PowerAppManagementApp registration (some heavily-governed tenants block this), you can grant the service principal Environment Admin on each environment individually:
- Open the Power Platform Admin Center.
- Go to Environments and click each environment you want scanned.
- Under Access → Environment Admin, click Edit.
- Add the Application (client) ID of your MigrationFox service principal. Environments only accept object IDs here — if the search doesn't resolve by name, paste the Object ID from Azure AD → Enterprise Applications.
This is more effort (repeat per environment), but it works when tenant-app registration is blocked. MigrationFox will detect the access automatically on the next scan.
Related
- Dependency Graph scan — what runs against these APIs
- Continuous monitoring — re-uses the same permissions
- Microsoft: PowerShell support for Power Platform administrators