Workflow Input Block
Call a child workflow and map values field-by-field to its Start block schema
The Workflow Input block calls another workflow as a child of the one you're building, the same way the Workflow block does. The difference is in how you hand it data: instead of passing one generic value, it reads the child workflow's Start block schema and gives you a dedicated mapping row for every field that block declares, so the child receives a structured object with matching keys rather than a single lump input.
This block and the Workflow block both run under the type name "Workflow" and
share the same execution engine — they differ only in how inputs are mapped in. This page covers
the field-mapping variant (internal type workflow_input). See the Workflow
block for the older single-variable variant, which is kept around for workflows built before this
mapping UI existed but is no longer offered when you add a new block from the toolbar.
Overview
The Workflow Input block enables you to:
- Call a child workflow by name: Pick any other workflow in the workspace from a searchable dropdown. The active workflow is excluded from the list to prevent self-reference loops.
- Map inputs field-by-field: Once a child workflow is selected, the block renders one mapping row per custom field added under that child's Start block Inputs section.
- Wire each field independently: Each row accepts a literal value or a variable/output reference from the current workflow, so different parents can feed the same reusable child different data through clearly named fields instead of agreeing on one packed value.
- Read structured results back: After the child finishes, its final output, success state, and any error are exposed as outputs you can reference downstream.
Configuration Options
Select Workflow
A required combobox listing every workflow in the workspace except the one you're currently editing. Choosing a workflow here is what unlocks the Input Mapping field below it.
Input Mapping
Once a child workflow is selected, this field renders dynamically from that child's Start block schema — one row per declared field. For each field you can supply:
- A literal value, or
- A reference to a variable, trigger field, or another block's output in the current workflow
Leave a field's row empty and that key simply isn't sent to the child.
If the child workflow's Start block schema changes later — a field gets renamed or removed — Mandala automatically drops the now-invalid rows from this mapping the next time the parent runs, rather than silently sending stale data.
Outputs
| Output | Type | Description |
|---|---|---|
success | boolean | Whether the child workflow completed without errors. |
childWorkflowName | string | The name of the workflow that was executed. |
result | json | The child workflow's final output. |
error | string | Error message when the run fails. |
How to Use
- Add the block and choose the child workflow from Select Workflow.
- Open Input Mapping. Mandala reads the selected child's Start block and lists every custom field added to that Start block's Inputs section. A child with no custom fields shows no mapping rows.
- Map each field to a literal value or a variable/output from the current workflow. Only fields with a mapping are sent through.
- Deploy if needed. When the parent workflow runs from an API call, schedule, webhook, or chat execution, the block calls the child's latest deployed snapshot — redeploy the child after changing its schema or logic so the mapped fields line up. A manually triggered parent run is the one exception: it calls the child's current draft state instead, so you can test changes to the child without redeploying it first.
- Use the outputs downstream, e.g.
<blockName.result>,<blockName.success>,<blockName.childWorkflowName>, or<blockName.error>.
Example Use Cases
Order Processing Sub-Workflow
Scenario: A reusable child workflow expects customerId, sku, and quantity
- Parent workflow collects an order from a form or API call
- Workflow Input block maps
customerId,sku, andquantityindividually to the child's Start block fields - Child workflow validates stock and creates the order
- Parent reads
<orderWorkflow.result>to continue with confirmation logic
Shared Notification Workflow
Scenario: Multiple parent workflows send notifications through one child
- Child workflow's Start block declares
channel,recipient, andmessagefields - Each parent workflow uses its own Workflow Input block, mapping different variables into the same three fields
- Notification logic (formatting, provider selection, retries) lives in one place instead of being duplicated
Multi-Entry-Point Onboarding
Scenario: Webhook, form, and agent flows all onboard users through the same child workflow
- Child workflow's Start block declares
name,email, andplanas custom Input fields - A webhook-triggered parent maps payload fields into those three names
- A form-triggered parent maps its own field names into the same three
- Both stay readable because each field is mapped and named explicitly, rather than merged into one opaque value
Execution Notes
- Child workflows run in the same workspace context, so environment variables and workspace tools carry over.
- Nesting is capped at 10 levels deep to prevent runaway recursion between workflows that call each other.
- If the child fails, the block returns
success: falseand populateserror— handle this downstream or the failure will surface as the block's error.