Azure Logic Apps Parent-Child Pattern: "Choose a Logic App Workflow" Returns InternalServerError but Direct HTTP Trigger Works

Alan Chen 0 Reputation points
2026-08-10T15:10:52.88+00:00

Hi all,

I'm trying to implement a Parent-Child architecture using Azure Logic Apps (Consumption). The parent workflow can execute the child one.

Environment

  1. Parent Logic App: Consumption
  2. Child Logic App: Consumption
  3. Both Logic Apps are in the same Resource Group
  4. Child trigger: When an HTTP request is received
  5. Parent action: Choose a Logic App Workflow

User's imageUser's image

Issue

I selected my Child Logic App in the Parent workflow using the Choose a Logic App Workflow action.

When the Parent runs, the action fails with:

  1. Error messge from this action: I****nternalServerError Encountered internal server error. The tracking Id is 'a8f9f484-b713-4822-9060-xxxxxxx'.
  2. action status = failed
  3. outputs is {}.
  4. In child run history there is no history appeared, it appears the Child workflow is never triggered.

User's image

User's image

What I Have Already Verified

  • Both of the azure logic apps are consumption model and created under same resource group.
  • there is no restriction for IPs .
  • Child url can be triggered using HTTP action from parent workflow and from postman with the same JSON payload structure.
  • Authentication/authorization appears valid.

Could you help me to diagnose the root cause for this issue and is there any way to fix the problem? Thanks a lot!

Azure Logic Apps
Azure Logic Apps

An Azure service that automates the access and use of data across clouds without writing code.

0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Gursimran Singh 570 Reputation points Microsoft External Staff Moderator
    2026-08-10T20:15:24.4633333+00:00

    Hi @Alan Chen ,

    Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

    The fact that direct HTTP calls (and Postman) succeed while "Choose a Logic Apps workflow" fails — combined with zero trigger history on the child — is the key clue here. It means the request is failing before it ever reaches the child's trigger, so this isn't a payload or trigger-schema issue.

    Why these two paths behave differently

    • The HTTP action (and Postman) call the child's trigger endpoint directly, authenticated via the SAS signature in that callback URL.
    • "Choose a Logic Apps workflow" is a built-in connector action that resolves and invokes the child through the Azure Resource Manager (ARM) control plane, using the parent Logic App's own resource identity/permissions — not the trigger's SAS key.

    So a working HTTP call doesn't rule out an issue on the nested-invoke path. Things to check, in order of likelihood:

    1. Stale action reference. If the child was renamed, redeployed, or its trigger was ever resaved (which regenerates the callback URL) after you first configured the parent's action, the parent may be holding a stale resource reference. Fix: open the "Choose a Logic Apps workflow" action, re-pick the child from the picker again, and save the parent.
    2. RBAC on the child resource. The parent Logic App needs at least Logic App Contributor (or Contributor) role scoped to the child's resource group or resource. Being in the same resource group doesn't guarantee this — check IAM on the child resource specifically, since role assignments can be scoped narrowly.
    3. Recreate the action. If the reference and permissions both look fine, try deleting the "Choose a Logic Apps workflow" action entirely and re-adding it fresh, reselecting the child. This clears any cached resolution that might be causing the immediate failure.

    In the meantime: continuing to call the child via its HTTP trigger URL is a valid workaround, but you'll be managing the callback URL/SAS key yourself instead of relying on the built-in resource reference.

    Please "upvote" if the information helped you. This will help us and others in the community as well.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.