Restrict Logic App (Consumption) to be invoked only by specific Logic Apps
Published Mar 21 2023 02:21 PM 3,734 Views



Configure a Logic App (Consumption) so that it can be called/invoked by other specific Logic Apps only. There is no built-in way to restrict calls from only particular workflows, so this requires a bit of configuration in the workflow itself. It is possible that the Logic App will trigger, but it doesn’t have to execute any of the actions afterwards.


This also expects that the parent Logic App(s) invoke the child Logic App using the built-in 'Azure Logic Apps' action.





Services Used


  • Azure Logic Apps (Consumption)
    • A child Logic App
    • A parent Logic App #1
    • A parent Logic App #2 (Optional)
  • Postman (Optional)




Step 1: Set up the child Logic App to first restrict calls from only other Logic Apps. Then, we’ll add a Condition statement within the workflow to double check that caller indeed is the “approved” Logic App. The child Logic App is named ChildLogicApp in this tutorial.


ChildLogicApp Workflow Settings

  1. On the Logic App, navigate to Settings > Workflow Settings blade
  2. Under the Access control configuration, select Only other Logic Apps from the dropdown
  3. Save the new settings





ChildLogicApp Designer/Workflow Configuration

  1. Open the Logic App Designer
  2. Add the trigger: When a HTTP request is received
  3. Add the action: Response
  4. Add a control action: Condition

When the parent Logic App invokes the child Logic App, it will send over some static fields/properties in the headers. One of those headers is ‘x-ms-workflow-name’, which contains the name of the caller Logic App.


  1. Set the condition statement of the Condition block to:
    1. ‘x-ms-workflow-name’ is equal to [AuthorizedParentLogicApp]

Note: If you have more than one allowed parent Logic App that can invoke the Logic App, you can adjust the Condition block accordingly, by selecting the ‘Or’ operator, and adding an entry/line for each allowed workflow name.




You might need to go into the Logic App’s Code View to directly reference this header property. The highlighted line is the left side of the expression, like so:



"expression": {
                    "and": [
                            "equals": [




Here’s the overall flow of ChildLogicApp. Any Logic App using the built-in Logic App Workflow action can invoke it, but only approved Logic App will pass the Condition block and later execute the rest of the flow, along with a Response action that is usually required for the parent workflow to execute successfully when using the Azure Logic Apps connector. If an unapproved Logic App invokes the Logic App using the Azure Logic Apps connector, the Condition will evaluate to false and the flow will terminate immediately.

If an approved parent workflow invokes ChildLogicApp, it will receive the appropriate response that's specified in the true block.

If an unapproved parent workflow invokes ChildLogicApp, it will fail due to not receiving a response since the false block executed.







Step 2: Set up the approved parent Logic App to invoke ChildLogicApp using the Logic App Workflow action. The approved Parent Logic App is named AuthorizedParentLogicApp in this tutorial.


AuthorizedParentLogicApp Designer/Workflow Configuration

  1. Open the Logic App Designer
  2. Add the trigger: When a HTTP request is received (or any other trigger)
  3. Search for the Azure Logic Apps connector, and select the ChildLogicApp

Repeat steps 1-3 for any other approved parent Logic Apps.




Here’s the overall flow of AuthorizedParentLogicApp, which uses the Azure Logic Apps connector to invoke ChildLogicApp. There are no additional Body/Headers required for the demo.




Step 3: Run AuthorizedParentLogicApp so that it invokes ChildLogicApp.


Here’s the sequence of events of ChildLogicApp that was just invoked. The Condition expression results in true and performs whatever logic exists in that block.





That’s all there is to the setup.


Below is an alternative setup to the ChildLogicApp which makes use of trigger conditions and determines whether or not to even execute the flow. In this case, the Condition step is not required or used, and an unapproved parent Logic App will still succeed with a 202, rather than fail. 


Alternate ChildLogicApp Designer/Workflow Configuration

You can also set up the trigger condition to prevent the child Logic App from executing in the first place. In this case, an unapproved parent Logic App will exit with a status of 202. 


  1. Open the Logic App Designer
  2. Select the trigger's settings: When a HTTP request is received
  3. In the trigger conditions, add the following statement

@equals(triggerOutputs()['headers']?['x-ms-workflow-name'], 'AuthorizedParentLogicApp')


UnauthorizedParentLogicApp succeeds with 202.




The Fired status is empty.






For optional testing and attempting to ‘break’ this configuration, see the below options.


Optional Testing


Test 1: Use an HTTP action from within AuthorizedParentLogicApp to invoke ChildLogicApp


Here, if you try to invoke ChildLogicApp directly with the HTTP action by passing in the callback URL and hardcoding the header “x-mx-workflow-name” : “AuthorizedParentLogicApp”, the Logic App fails with Unauthorized on the HTTP because the Only other Logic Apps setting on ChildLogicApp determines that only calls from parent logic apps that use the built-in Azure Logic Apps action can trigger the nested logic app.



  "error": {

    "code": "AuthorizationFailed",

    "message": "The client IP address '<>' is not in the allowed caller IP address ranges specified in the workflow access control configuration."










Test 2: Use an external tool Postman to invoke ChildLogicApp


Using a different tool (Postman) outside of Azure to invoke ChildLogicApp directly fails with Unauthorized as well, stating the same error as in Test 1.





Test 3: Create a different unauthorized parent Logic App (UnauthorizedParentLogicApp) to attempt to invoke ChildLogicApp.


Hardcode the header ‘x-ms-workflow-name’ to AuthorizedParentLogicApp.





While Option 1 and Option 2 resulted in immediate failures in the caller, ChildLogicApp will still trigger, but it will not execute any of the subsequent actions. Despite attempting to override the header, the actual name of the parent Logic App UnauthorizedParentLogicApp was preserved in the trigger outputs of ChildLogicApp.





So, the Condition expression evaluates to false and the flow terminates immediately. 





1 Comment
Version history
Last update:
‎Mar 21 2023 05:06 PM
Updated by: