Fix Power Automate HTTP trigger URLs after the logic.azure.com retirement

If a Power Automate flow with a When an HTTP request is received or Teams webhook trigger stopped running, the most likely cause is that its callers still use the old trigger URL containing logic.azure.com: for flows in environments on the Logic Apps architecture, those URLs stopped working on November 30, 2025. The fix is to list the affected flows with Get-AdminFlowWithMigratingTriggerUrl, copy the new URL from each flow's trigger card and replace the old URL in every system that calls the flow. If callers then receive authentication errors such as 401, the trigger's Who can trigger the flow setting needs a bearer token whose audience, tenant and object ID claims match exactly.

Who this is for and what you will have at the end

This guide is for Power Platform administrators and developers who own integrations that start flows over HTTP: line-of-business apps, Azure services, scripts, Power Apps, other flows and third-party SaaS products that post to a flow URL. At the end you will have:

• A tenant-wide list of flows whose trigger URLs migrated, with their owners.
• A process for replacing the URL in each caller and validating it.
• An understanding of the three trigger authentication modes and the token claims each needs.
• A troubleshooting list for the failures that follow URL changes.

What changed

Microsoft is moving Power Automate environments from the original Logic Apps-based architecture to a new architecture called SelfHost Multitenant. As part of that infrastructure upgrade, flows with HTTP triggers or Teams Webhook triggers that have logic.azure.com in the URL moved to a new URL. Microsoft's troubleshooting article sets out the timeline:

• Before November 30, 2025, both the old and new URLs were supported.
• Starting November 30, 2025, the old URLs stop working and flows don't trigger.
• The change affects only flows that have HTTP or Teams Webhook triggers, and only flows in environments on the Logic Apps architecture. Environments already on SelfHost Multitenant are not affected.

Two further details matter in practice:

• URL length. The new URL might be longer than 255 characters, especially with Shared Access Signature (SAS) authentication. Callers with a 255-character field limit need a configuration change, or a proxy such as Azure API Management or Azure Functions in front of the flow.
• A second, optional change. Starting June 2, 2026, a change in the Power Automate proxy layer exposes the scale unit identifier in the HTTP trigger callback URL, for example /direct/cu/20/workflows/... instead of /direct/workflows/.... Microsoft recommends updating integrations to the new form for better performance, but states that the old form continues to work.

Affected flows show a warning banner on the details page or in the designer: "Click here to copy the new trigger URL. The old trigger URL ... stops working on November 30, 2025." If a flow with an HTTP or Teams webhook trigger has no banner, its environment is most likely on SelfHost Multitenant and the flow is not affected.

Prerequisites

• Windows PowerShell 5.x. The Power Apps administration modules use .NET Framework and are not compatible with PowerShell 6 and later.
• The administration module. Install Microsoft.PowerApps.Administration.PowerShell (add -Scope CurrentUser if you are not a local administrator).
• An admin role. The Admin cmdlets are meant for Power Platform administrators. Microsoft notes that without an admin role on the tenant you're limited to the resources you own, so run the tenant-wide report with an administrator account.
• Access to the callers. You need someone who can change configuration in each external system that calls a flow.

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -Scope CurrentUser
Add-PowerAppsAccount

For GCC, GCC High or DoD tenants, connect with Add-PowerAppsAccount -Endpoint set to usgov, usgovhigh or dod.

Step 1: Check the environment architecture

For a single environment, you can check the architecture in the maker portal:

1. Sign in to Power Automate and select the environment in the upper right.
2. Press Ctrl + Alt + A to show the environment debug information.
3. Search for environmentFlowHostingType.

A value of SelfHostMultiTenant means the environment is on the new architecture and no action is required. A value of LogicApps means it is on the current architecture and the flows in it are candidates for the URL change. Microsoft also notes that flows still using old trigger URLs can block an environment's automatic upgrade, so cleaning them up has a second benefit.

Step 2: List affected flows across the tenant

Get-AdminFlowWithMigratingTriggerUrl takes a mandatory -EnvironmentName (the environment ID, not the display name) and returns the DisplayName and FlowName of each flow whose trigger URL is migrating. Loop it over every environment and export the result:

$report = foreach ($env in Get-AdminPowerAppEnvironment) {
    $flows = Get-AdminFlowWithMigratingTriggerUrl -EnvironmentName $env.EnvironmentName
    foreach ($flow in $flows) {
        [pscustomobject]@{
            Environment     = $env.DisplayName
            EnvironmentName = $env.EnvironmentName
            FlowDisplayName = $flow.DisplayName
            FlowName        = $flow.FlowName
        }
    }
}
 
$report | Export-Csv -Path .\migrating-trigger-urls.csv -NoTypeInformation
$report | Format-Table -AutoSize

Then add the owners, because they are the people who know which systems call each flow:

foreach ($row in $report) {
    Get-AdminFlowOwnerRole -EnvironmentName $row.EnvironmentName -FlowName $row.FlowName |
        Select-Object @{n='Flow';e={$row.FlowDisplayName}}, RoleType, PrincipalObjectId
}

The owner records give object IDs; resolve them to names in Microsoft Entra ID before you contact people. If an owner has left, assign a co-owner with Set-AdminFlowOwnerRole first, otherwise nobody can open the flow to copy the new URL.

Step 3: Copy the new URL and find every caller

For each flow in the report, open it in the designer and copy the URL from the HTTP trigger card, or use the link in the warning banner. Record both the old and new URL; the banner shows the old URL that was replaced.

Finding callers is the harder part, because nothing in Power Automate records who holds the URL. Work through these sources:

• Application configuration and code. Search configuration files, app settings, key vaults and source repositories for logic.azure.com and for the workflow ID that appears in the URL path.
• Other flows. A parent flow that calls a child flow through an HTTP action is an external caller and must be updated. A child flow called through the Run a child flow action needs no change.
• Power Apps and solutions. Apps or solution components that stored the URL as a variable or environment variable value.
• SaaS products. Outbound webhook settings in monitoring, ticketing, CI/CD and HR systems.
• Teams webhooks. Senders that were moved from Office 365 Connectors to a Workflows webhook earlier may hold a logic.azure.com URL too; see Replacing Teams incoming webhooks with Workflows for that side of the migration.

Step 4: Replace the URL and validate

Update each caller with the new URL, then trigger the flow and confirm a successful run in its run history. Microsoft's validation steps call out two specific checks:

• Length. If you use SAS authentication, confirm the caller accepts URLs longer than 255 characters.
• Relative path. If the trigger uses a relative path parameter, make sure there are no backslashes in the field that could cause double-slash errors, then verify the full trigger URL.

A quick test from PowerShell for a trigger set to Anyone:

$uri  = '<new trigger URL from the trigger card>'
$body = @{ orderId = 'TEST-001'; source = 'url-migration-test' } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri $uri -ContentType 'application/json' -Body $body

If the SAS URL leaked during the migration (pasted into tickets or chat), regenerate the key afterwards. The sig= parameter in the URL changes when the key is regenerated, and the old signature stops working, so do it before the final caller update, not after.

Step 5: Understand trigger authentication before you debug 401 errors

The HTTP trigger has a Who can trigger the flow parameter with three modes:

Because Any user in my tenant is the default for new flows, a flow rebuilt or recreated during the migration can end up with authenticated access where the original allowed anyone, unless you change the setting back. Callers that never sent a token then start failing.

When the trigger requires authentication, the token must contain:

• aud: the Power Automate audience for your cloud, matched exactly including the trailing slash.
• iss: the issuer of the requester.
• tid: the requester's tenant ID.
• oid: the requester's object ID, required only for Specific users in my tenant.

For a service or script, use an app registration with the client credentials flow and add its service principal's object ID to Allowed users if you use the specific-users mode. Because the audience ends with a slash, Microsoft's scope guidance says to request the .default scope with a double slash:

$tenantId = '<tenant ID>'
$tokenResponse = Invoke-RestMethod -Method Post `
    -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `
    -ContentType 'application/x-www-form-urlencoded' `
    -Body @{
        client_id     = '<app (client) ID>'
        client_secret = '<client secret>'
        scope         = 'https://service.flow.microsoft.com//.default'
        grant_type    = 'client_credentials'
    }
 
$token = ConvertTo-SecureString $tokenResponse.access_token -AsPlainText -Force
Invoke-RestMethod -Method Post -Uri $uri -ContentType 'application/json' `
    -Authentication Bearer -Token $token -Body $body

The -Authentication Bearer -Token parameters need PowerShell 6.0 or later, so run caller tests in PowerShell 7 rather than in the Windows PowerShell 5.1 session you used for the admin module. Microsoft suggests checking the claims by pasting the token into jwt.io; do that once for each new caller.

Firewalls and outbound rules

If callers sit behind an outbound firewall, Microsoft's IP address configuration article lists the domains to allow for the When an HTTP request is received trigger. For the public cloud they are *.api.powerplatform.com and *.logic.azure.com; government and China clouds have their own pairs listed in the same article. A caller that was only allowed to reach logic.azure.com hosts can fail after the URL change even though the URL is correct.

Verification

• Every flow from the Get-AdminFlowWithMigratingTriggerUrl report has a recorded owner, old URL, new URL and list of callers.
• Each caller has been updated and produced at least one successful run.
• No new failed or missing runs appear in the run history over the following business cycle (daily, weekly or month-end jobs).
• Re-running the report shows no flows you have not already handled.

Troubleshooting

The flow never runs when the caller posts. The caller most likely still uses the old logic.azure.com URL. Compare the URL in the caller with the URL on the trigger card character by character; truncated query strings are common when a field is limited to 255 characters.

401 or authorization failures after the URL update. Check the trigger mode first. If it is Any user in my tenant or Specific users in my tenant, the caller must send a bearer token. Decode the token and confirm aud matches the audience for your cloud exactly, tid is your tenant, and for specific users, oid is on the allowed list. If you leave Allowed users empty, any user in the tenant can trigger the flow.

Failures with a token when the trigger is set to Anyone. For the Teams webhook trigger, Microsoft states that requests to a trigger set to Anyone fail if they include an authentication token header. Remove the header or change the trigger mode.

Double slash in the path. A relative path parameter containing backslashes produces malformed URLs. Remove them and re-copy the URL.

URL cut off by the calling system. The new URL can exceed 255 characters. Increase the field length, or put Azure API Management or an Azure Function in front of the flow and give callers a short stable URL.

Callers behind a proxy fail with connection errors. Add *.api.powerplatform.com to the outbound allow list alongside *.logic.azure.com.

No banner, no report entry, but the flow still fails. The environment is probably on SelfHost Multitenant, so the URL change is not the cause. Check trigger authentication, data policies and connection status instead.

Checklist

• Admin module installed in Windows PowerShell 5.x and signed in with Add-PowerAppsAccount.
• Get-AdminFlowWithMigratingTriggerUrl run for every environment and exported.
• Owners identified; orphaned flows given a co-owner.
• New URL copied from each trigger card; callers found and updated.
• Child flows called through HTTP actions updated; Run a child flow calls left alone.
• URL length and relative path checked.
• Trigger authentication mode confirmed and token claims verified for authenticated callers.
• Outbound firewalls allow *.api.powerplatform.com.
• SAS key regenerated if the URL was exposed.

References

• Troubleshoot common problems with Power Automate triggers
• Power Automate environments move to new architecture
• Get-AdminFlowWithMigratingTriggerUrl
• PowerShell support for Power Apps and Power Automate
• Add OAuth authentication for HTTP request triggers
• Regenerate the SAS key used in HTTP trigger flows
• Power Automate IP address configuration
• Manage orphaned flows when the owner leaves the organization
• Microsoft Teams connector reference
• Scopes and permissions in the Microsoft identity platform
• Invoke-RestMethod