Following my last blog post, where I addressed BizTalk Server Orchestration Parameters, I’d like to explain the same paradigm in Logic Apps. Similar to BizTalk Server, Logic Apps allows you to call a workflow synchronously, as in the BizTalk Call Orchestration model. Here, the parent workflow invokes a child and waits for it to finish, much like calling a method in code. And the ability to call a workflow asynchronously, using the “publish and start” model, similar to the BizTalk Start Orchestration pattern. Here, the parent workflow invokes a child but doesn’t wait; it can move on or complete while the new instance runs independently.
Unlike BizTalk Server, where we can pass different types of parameters (messages, variables, …) as In, Out, or Ref. When one Logic App calls another, the “parameters” you pass are simply the child’s trigger inputs. In practice, there are two clean ways to structure this:
- Call a workflow inside the same Logic App Standard app with the built-in Workflow action.
- Of course, you can also use the Workflow action (managed connector) to call a Logic App Consumption.
- Or call any workflow (Standard or Consumption) over HTTP. Both are just contracts between the caller and the child’s trigger.
If you’re using Logic Apps Standard or Consumption, the smoothest option is the Workflow action. In order to use the Workflow action/Logic App Connector, the child must start with the When an HTTP request is received trigger.
Inbound “parameters”
As mentioned before, when one Logic App calls another, the “parameters” you pass are simply the child’s trigger inputs, being them:
- The body payload.
- And/or the HTTP Headers.
- Query and/or URI parameters
In the child, on the start shape: When an HTTP request is received trigger, you can define a body schema that represents your parameters—strings, numbers, booleans, arrays, or objects. In the picture below we will see input1 and input2:
That schema is your contract. In the parent, drop the Workflow action, pick the child by name, and map values into the child’s JSON body.
Note that the JSON schema in the child workflow is not mandatory! If you specify that you are kind of closing the contract between them. Notice that in the picture above, the primary workflow recognizes that the child workflow expects two inputs: input1 and input2. If you don’t specify:
It will become an open contract:
Both approaches have advantages and disadvantages.
Now, HTTP Headers are also a way to send inbound “parameters” to a child workflow, and they should be used, especially when we send the body of a message to be processed by the child workflow. And all the control parameters as headers. It is a good best practice to use the body for documents (messages) and HTTP Headers for control variables values (for custom flags, correlation IDs, etc.).
Now, if you want to use query parameters or URI Parameters, the Azure Logic App connector – Choose a Logic Apps workflow action does not support them! Instead, you need to use the classic HTTP connector to use that strategy for inbound parameters.
Logic Apps allows you to use path (URI) or query parameters. For the URI parameters, we need to include them in the trigger’s relative path:
Query parameters you can add to the end of the URL; you cannot specify them in the child workflow, but you can retrieve them.
In this case, the child exposes an endpoint via the Request trigger; the parent calls it with an HTTP action. Your parameters live in the body (for structured JSON), the path (for identifiers), or the query/headers (for optional switches, versioning, correlation).
Outbound “parameters”
For the Outbound parameters are almost the same, but in this case, we can only use:
- The body payload.
- And/or the HTTP Headers.
The child returns data through a Response action; whatever JSON you send back becomes the parent’s action outputs. This gives you a tidy, synchronous “call and wait” model with typed inputs and outputs.
Of course, the outbound “parameters” can only be used in the synchronous calls. Async calls do not have outbound “parameters”.
Best practices
Despite it being a good practice for REST APIs, in the case of parent-child workflows, try to avoid using URI or Query parameters. Instead, it is a good best practice to use the body for documents (messages) and HTTP Headers for control variables values (for custom flags, correlation IDs, etc.). And for security reasons, choose always to use the Azure Logic App connector – Choose a Logic Apps workflow action instead of the HTTP Connector. Use the HTTP Connector as a last option. If the Azure Logic App connector, for some reason, doesn’t work, it is better to expose it through API Management and use the APIM Connector instead of the HTTP Connector.
In general, the child workflow exposes an endpoint via the Request trigger; the parent calls it via a Logic App action, an API Management action, or an HTTP action. Your parameters live in the body (for structured JSON), the path (for identifiers), or the query/headers (for optional switches, versioning, correlation). The child responds with Response. This pattern is handy when the child runs in a different app, subscription, or region, or when you want to place API Management in front for governance, caching, and policies.
In short, “parameters” in Logic Apps are just trigger inputs, and “returns” are Response outputs. Model your contract in the child’s Request trigger, pass values from the parent via the Workflow or HTTP action, secure the hop with managed identity or APIM, and be explicit about whether you’re waiting for a reply or not.
Hope you find this helpful! If you enjoyed the content or found it useful, and wish to support our efforts to create more, you can contribute to purchasing a Star Wars Lego set for my son!
