> ## Documentation Index > Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt > Use this file to discover all available pages before exploring further. # Passing data between nodes > How outputs from subprocesses, workflows, AI agents, and business rules land in process variables, and how downstream nodes read them. ## Overview Inside a BPMN process, every node, including subprocess, integration workflow, AI agent, business rule, and user task, reads from and writes to a shared store of **process variables** (also called *process instance data* in code). This page explains the mental model: where each node type's output lands, and how the next node, or a user task screen, reads it. For the configuration syntax of any specific mapping, follow the links to the dedicated pages. If you are calling FlowX from an external app (React frontend, another backend service) and want to fetch a process result over HTTP, that is a different question. See [Consuming FlowX from external apps](../../platform-deep-dive/integrations/consuming-flowx-from-external-apps). *** ## The mental model A process variable is a key on the process instance data store. Every node configures: * **Input mapping**: which existing process variables to send into the node, or how to compute them. * **Output mapping or result key**: where the node's output is written back into the process variables. After the node finishes, downstream nodes and any user task screens that follow can read the result by referencing that key. ``` ┌──────────────────────────────────────────────────────────┐ │ Process variables (shared store) │ └──────────────────────────────────────────────────────────┘ ▲ ▲ ▲ ▲ │ output │ output │ output │ read │ │ │ │ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐ │ Subprocess│ │ Workflow │ │ AI agent │ │ User task │ └───────────┘ └───────────┘ └───────────┘ └───────────┘ ``` *** ## Choose the right pattern | If you need to… | Use this node | Where its output lands | Reference | | ---------------------------------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Run a stateful, multi-step BPMN flow with its own user tasks | Subprocess (call activity) | Mapped into parent variables via Data Mapper | [Data mappers](./data-mappers) | | Call an integration workflow (REST, DB, AI ops) and capture the result | Send Message Task with **Start Integration Workflow** action | Written to the configured **Result key**, then a **Receive Message Task** unblocks the process | [Start Integration Workflow](../actions/start-integration-workflow) | | Call an AI agent (extraction, decision, generation) | Service Task with the agent integration | Mapped back to process variables in the action's output mapping | [BPMN integration with agents](../../../ai-platform/using-agents/bpmn-integration) | | Compute or transform values inline | Business Rule action | Writes to keys passed to `output.put(key, value)` | [Business rule action](../actions/business-rule-action/business-rule-action) | *** ## The Receive Message Task pattern (workflows) This is the part most people miss the first time. When a process triggers an integration workflow with **Start Integration Workflow**, the process must wait for the workflow to finish before reading its output. To wait, place a **Receive Message Task** after the Send Message Task that triggers the workflow. Configure it with the **Start Integration Workflow** action. Set the **Result key**: this is the process-variable path where the workflow's output will be written. The process pauses on this node until the workflow completes. When it completes, the workflow's output lands at the result key. Any node after the Receive Message Task, including gateway, business rule, and user task, can read the result key from process variables. For the full configuration walkthrough, see [Start Integration Workflow → Receiving output](../actions/start-integration-workflow#receiving-output) and [Send/Receive Message Task nodes](../node/message-send-received-task-node). **For AI agents:** the integration is typically wired on a Service Task, and the agent's response is mapped back to process variables in the action's output mapping. No separate Receive Message Task is required. See [BPMN integration with agents](../../../ai-platform/using-agents/bpmn-integration). *** ## Reading process variables downstream Once a value is in process variables, the way you reference it depends on where you are reading from: * **In another node's input mapping** (Send Message Task action, agent input, etc.): use the placeholder syntax documented on that node's page. Example for workflow input mapping: `${processInstanceData.customer.id}` (see [Start Integration Workflow → Input mapping](../actions/start-integration-workflow#input-mapping)). * **In a subprocess's Data Mapper**: use `${variableName}` against the subprocess's defined Input Parameters. The Data Mapper is the canonical interface for parent ↔ subprocess data flow (see [Data mappers](./data-mappers)). * **In a business rule script**: read from `input` (the keys you mapped in) and write to `output` via `output.put("keyName", value)`. See [Business rule action](../actions/business-rule-action/business-rule-action). * **In a gateway condition**: reference the same process variables to choose a path. * **In a user task screen**: bind UI components to process data. The value flows automatically once the variable exists in process instance data. The placeholder prefix is **not** universal. Subprocess Data Mappers use `${variableName}`; integration node config (workflow input, KB lookups) uses `${processInstanceData.path}`. Always follow the syntax shown on the destination page. *** ## End-to-end example A loan-onboarding process that uses an integration workflow to fetch a credit score, then an AI agent to extract data from an uploaded document, then a user task to confirm the final summary. The file id lands on process variables, for example at `loan.documentId`. Input mapping reads `loan.customerId`. Result key set to `creditCheck`. When the workflow completes, its response lands at `creditCheck` in process variables. Input mapping sends `loan.documentId`. Output mapping writes the extracted fields to `loan.extracted`. UI components on the screen are bound to `creditCheck` and `loan.extracted`. They render automatically because both keys now exist in process variables. *** ## Common pitfalls The result key only contains data after the Receive Message Task unblocks. A node placed between Send and Receive will see an empty value. Two integrations writing to the same result key will overwrite each other. Use distinct, descriptive paths (`creditCheck`, `addressVerification`) instead of generic ones (`result`, `data`). `${variableName}` works in subprocess Data Mappers; `${processInstanceData.path}` works in integration node config. Mixing them produces unresolved placeholders at runtime. Follow the syntax shown on each node's page. Starting a process via REST returns metadata (process instance UUID, state), not the process's business output. To surface results to an external app, use the SDK, a Service Task callback, or a Kafka event. See [Consuming FlowX from external apps](../../platform-deep-dive/integrations/consuming-flowx-from-external-apps). *** ## Related resources Parent ↔ subprocess parameter mapping Workflow input/output and the Receive Message Task pattern Calling AI agents from a process Inline scripts that read from `input` and write to `output` Node-level configuration of the wait pattern External HTTP/SDK integration patterns