> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/technical-reference/workflow-execution/nested-workflow-inputs-outputs-and-identity.md).

# Nested Workflow Inputs, Outputs, and Identity

A nested workflow uses another project as a processing step. Map its inputs and outputs separately from the parent’s visible interface.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSQ1Sgy933krTyK0S4JpP%2Fuploads%2FetyoI7AyLxJddyY1BdoL%2FG025A.mp4?alt=media&token=5437a55e-716b-4387-9937-79b098e9f9d7>" %}

## Before you begin

Access to the child project and its input/output schema.

## Key concepts

| Term            | Definition                                                                                                                                                   |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Parent workflow | The workflow that calls another project. It must map the child result into its own processing or visible output.                                             |
| Child workflow  | The project executed by a project node or project-execution tool. Review its input contract, selected version, permissions, and run details.                 |
| Schema          | A definition of fields, types, required values, and supported constraints. Use it to validate the shape of data; it does not establish factual correctness.  |
| Output mapping  | Selection of a node’s returned field for another step or the final interface. A successful intermediate result is not automatically visible to the end user. |
| User identity   | The authenticated person or application acting on a resource. It determines access; a display name or conversation ID does not authenticate a caller.        |

## Map inputs and outputs between workflows

1. Read the child inputs and map the corresponding parent values.

![Select the child workflow in the Beta node and review its input and loop settings.](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/sTvd1OsSusbVba1u5Vv9/assets/g025a-05-beta-setup.png)

Select the child workflow in the Beta node and review its input and loop settings.

2. Run the parent and retain the child run ID.
3. Map the returned child field to the next parent step or final output.

The parent receives the intended child value and the child execution remains traceable.

## Behavior and limitations

Child runs have their own inputs and results. Use the returned run details to investigate a child failure. Conversation behavior differs by node and loop mode: the original project node shares conversation across list items, while Beta keeps items separate. Conversation scope does not grant resource access.

## Related resources

[Compare the StackAI Project and Beta nodes](/guides-and-quickstarts/workflow-builder/compare-the-stackai-project-and-beta-nodes.md)

[Execution Order and Node Dependencies](/technical-reference/workflow-execution/execution-order-and-node-dependencies.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.stackai.com/technical-reference/workflow-execution/nested-workflow-inputs-outputs-and-identity.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.