> ## 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.

# Data mappers

> Visually map data transfers between components while maintaining full backward compatibility.

## Overview

Use Data Mappers to define how data flows between components. Add JavaScript transformations for complex scenarios.

### Key concepts

> [card] Source Components
>
> Send data to another component to trigger execution
>
> * Parent processes
> * Integration flows
> * Business rules

> [card] Destination Components
>
> Receive input from a source component to execute
>
> * Subprocesses
> * Workflows
> * Business rules

### Parameters & variables

Configure parameters and variables on the **Data Model** tab at process level.

> [tab] Input Parameters
>
> **Input Parameters**: Define the structure your component expects to receive for successful execution.
>
> **Input Variables**: Send actual data from source to destination component for execution.
>
> ![Input Parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp1.png)

> [tab] Output Parameters
>
> **Output Parameters**: Define the structure your component returns to the source component after execution.
>
> **Output Variables**: Return actual data from destination to source component after execution.
>
> ![Output Parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp2.png)

#### Parameter types by origin

> [accordion] Predefined Parameters
>
> Established before the mapping action (e.g., input of a subprocess or workflow). These typically belong to **destination components** with fixed requirements.

> [accordion] Flexible Parameters
>
> Defined during the mapping process. Associated with **source components** that specify where destination component data comes from.

## Quick reference

Looking for a specific syntax rule or behavior? Everything is in this table; the sections after it walk through each scenario in detail.

| You want to | Do this |
| - | - |
| Map a single value | Use interpolation syntax: `${variableName}`. This format differs from process key formats. |
| Map all attributes at once | **Auto-populate**: select the data model type from the dropdown. **Quick Mapping**: available when source and destination share the same data type. |
| Transform, filter, or compute a value | Click the **f(x)** function icon next to the parameter and write JavaScript. Every computed value must use a `return` statement. |
| Reference data inside JavaScript | `${...}` resolves a **path** to its value; it does not evaluate JavaScript inside the braces. Place the placeholder first, then chain methods on the result. |
| Map part of an array | Not possible from the UI: arrays map **wholesale**. Use function mode to filter or reshape. See [Transforming arrays](#transforming-arrays). |
| Chain array methods safely | Wrap the placeholder with an empty-array fallback so an unpopulated path doesn't make `.filter()` or `.map()` throw. Copy-ready snippets: [Transforming arrays](#transforming-arrays). |
| Map output from an async subprocess | Not possible: the parent doesn't wait, so async supports **input mapping only**. |
| Preview what will be sent | Click **test** to render the JSON payload using the example values from your data model. |
| Change the data model | Deleted and renamed attributes propagate to mappings automatically; **new attributes must be added and mapped manually**. |
| Change a multi-instance input/output array | Saving the array change **deletes the existing mappings**; reconfigure them afterward. |

***

## Prerequisites

> [!WARNING]
>
> Plan your Data Model carefully before implementing Data Mappers. Proper setup ensures success.

### Data Model hierarchy

Understand the data model hierarchy to implement Data Mappers effectively:

> [card] Project Data Model
>
> **Organization Level**: Define reusable data structures (e.g., "customer", "client type") that you can share across all processes and workflows within your project.

> [card] Library Data Model
>
> **Enterprise Level**: Create organization-wide standardized data types that you can reuse across multiple projects by including the library as a dependency.

> [card] Process Data Model
>
> **Process Level**: Define process-specific data structures while reusing components from project and library levels.

### Setup requirements

**1. Define Project Data Model First**

**Critical**: Define your project data model before creating processes. This enables:

* Reusability across processes and workflows
* Consistent data structures
* Improved error prevention
* Enhanced mapping experience

**2. Include Example Values**

Add meaningful example values to your data model attributes. This helps you:

* Visualize attribute meaning and expected values
* Test without separate mock data
* Improve your configuration experience

**3. Plan for Reusability**

Design data structures that can be shared across multiple components:

* Customer information structures
* Common business entities
* Standardized response formats

## Configuration

### Setting up process parameters

**1. Configure Input Parameters**

* Open the process you want to configure
* Navigate to the **Data Model**
* Select the **Input parameters** tab and click "Define parameters"

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp3.png)

> [!NOTE]
>
> Define parameters for each start node separately when you have multiple start nodes. Select nodes from the dropdown.
>
> ![Start node selection dropdown on the Input parameters tab for processes with multiple start nodes](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp4.png)

* Define the schema based on the process's Data Model
* Mark fields as optional if your component can function without those parameters. The optional flag indicates your component can operate without these parameters throughout its entire operation, not just during mapping.
* **Note**: This centralizes input definition at the subprocess level, replacing the previous "data to send" configuration on the parent process

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp5.png)

**2. Configure Output Parameters**

* Navigate to the **Data Model**
* Select the **Output parameters** tab
* Define the schema based on the process's Data Model

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/output_variables.png)

**3. Handle Multiple Start/End Nodes**

* View all start or end nodes when your subprocess has multiple nodes
* Use this for scenarios with exclusive gateways
* Configure parameters independently for each node

> [!NOTE]
>
> **Process Start Prompts**: When you start a process with defined input parameters, the system generates input prompts based on required parameters to help with testing and validation.

## Mapping scenarios

### Call activity mapping

#### Synchronous call activity

```yaml Prerequisites theme={"dark"}
- Parent process with defined Data Model
- Child process with input/output parameters on Data Model  
- Project-level data model for reusable structures
```

```yaml Configuration Steps theme={"dark"}
1. Define call-activity type node
2. Select subprocess to be called
3. Choose Data Mapper implementation (default)
4. Configure input/output mapping
5. Test mapping with example values
6. Save configuration
```

**1. Set Up Call Activity**

* In a process, define a **call-activity** type node
* Select the subprocess to be called
* **Data Mapping is now the default option**
* Toggle to "Switch to legacy mapping" if needed for backward compatibility

> [!NOTE]
>
> **Data mapping vs legacy mapping**
>
> The **Switch to legacy mapping** toggle picks between two mapping modes:
>
> * **Data mapping** (toggle **OFF**, the default): map each attribute visually in the mapping modal, driven by the declared data model, with a **Test** preview before storing. This is the mechanism this page documents.
> * **Legacy mapping** (toggle **ON**): the key-based mechanism used by configurations built before data mappers existed. Data is passed by key as-is, without the data-model-driven modal or the Test preview.
>
> Both modes work at runtime: legacy mapping is an alternative, not a deprecation. For the detailed comparison on message tasks, see [Legacy mapping vs data mappers](https://docs.flowx.ai/6.x/docs/building-blocks/node/message-send-received-task-node.md#legacy-mapping-vs-data-mappers).
>
> ![Data Mapping section of a call activity with the Switch to legacy mapping toggle turned off](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/legacy.png)

> [!NOTE]
>
> Existing actions that were configured before this update automatically retain legacy mapping—there is no need for you to modify them unless you want to switch to the new Data Mapping.

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp7.png)

**2. Map Input Parameters**

* View the subprocess's input parameters
* Click the "key icon" next to the parameter

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp8.png)

* **Source Component**: Current process (parent)
* **Destination Component**: Subprocess input parameters
* **Mapping Options**:
  * **Individual Mapping**: Map each attribute individually using interpolation syntax: `${variableName}`
  * **Auto-populate Mapping**: Select the data model types from dropdown for automatic mapping of all attributes
  * **Quick Mapping**: If source and destination have the same data type, use dropdown for automatic mapping of all attributes

> [!TIP]
>
> **Auto-populate Feature**: Instead of manually typing variable paths, select your data model types from the dropdown and the system will automatically populate all the mappings for you.

![Mapping modal with auto-populate dropdown selecting a data model type to fill all attribute mappings](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dmp9.png)

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/params_parent_process_dn.png)

* **Display Options**: You can view variables as schema or JSON format for better visualization
* **Variable Format**: When mapping manually, use interpolation syntax `${variableName}` - this format differs from process keys
* **Testing**: Click the "test" button to visualize the JSON payload using example values from your data model

![Test preview rendering the JSON payload built from the data model's example values](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/dm13.png)

**3. Map Output Parameters**

* Select the **Output** tab
* View subprocess's output parameters
* Select attributes in parent process data model for storing output
* Map subprocess output parameters (source) to parent process parameters (destination)

![Define parameters](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/sub_output.png)

**JavaScript Transformation**:

To access JavaScript transformations, click the **function icon** next to the variable you want to transform.

* **Use JavaScript functions** for data transformation and combination
* **Syntax Requirements**: All computed values must use `return` statements
* **Example**: `return ${userVerification.status} + " on " + ${userVerification.verificationDate}`

![JavaScript transformation editor opened from the function icon, combining variables with a return statement](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/interpolation.png)

**Data Reference Syntax**:

* **Dynamic values**: Use `${variableName}` syntax to reference dynamic values (same as used for variable mapping)
* **Example**: `return ${approverName} + " approved on " + ${date}`

**Testing and Persistence**:

* **Testing**: Use test button to see transformed output with example values
* **Value Persistence**: Previous values are saved until you click "confirmation" and "save"
* **Error Handling**: JavaScript errors trigger when functions encounter issues (e.g., reading property from undefined object)

**Type Handling**:

* System sends configured data even with type mismatches (e.g., string to number)
* Always validate your transformations before saving

**4. Save Configuration**

Save the mapping configuration for both input and output

#### Asynchronous call activity

> [!NOTE]
>
> For async nodes, output cannot be mapped as the parent process doesn't wait for completion.

**1. Set Up Async Call Activity**

* Define **call-activity** node or **Start Subprocess** action on User Task
* Select subprocess to be called
* Check the **Run async** toggle

**2. Map Input Only**

* Choose Data Mapper implementation
* Map input parameters from parent process (source) to subprocess (destination)
* Save input mapping configuration

### Parallel multi-instance mapping

Use parallel multi-instance mapping when you need to start multiple subprocess instances simultaneously—one for each element in an array from the parent process.

> [!NOTE]
>
> **When to use**: This pattern is ideal for batch processing scenarios like processing multiple shipping orders, validating multiple documents, or handling multiple customer requests in parallel.

#### Configuration options

When **Parallel Multi-instance** is enabled on a Call Activity node or Start Subprocess action, configure these options:

| Option | Description |
| - | - |
| **Input Array** | The array from the parent process. Each element spawns a subprocess instance. |
| **Output Array** | The array in the parent process where subprocess results are collected. |
| **Correlation Attribute** | The attribute used to match subprocess results back to the correct parent array element. |

![Parallel multi-instance configuration](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/call_activity_parallel_multi_instance.png)

#### Data mapping configuration

**1. Enable Parallel Multi-Instance**

* Open the **Call Activity** node or **Start Subprocess** action
* Enable the **Parallel Multi-instance** toggle

**2. Declare Arrays**

* **Input Array**: Specify the parent process array containing the data to process (e.g., `ordersList`)
* **Output Array**: Specify where to store the subprocess results (e.g., `processedOrdersList`)

**3. Configure Input Mapping**

* Click to open the mapping modal
* Map array element attributes to subprocess input parameters
* **Example**: Map `${item.orderId}` from parent array to `orderId` in subprocess

![Parallel multi-instance mapping](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/pmi_mapping.png)

**4. Configure Output Mapping**

* Map subprocess output parameters back to the parent output array
* Each subprocess instance's result is added to the output array

**5. Set Correlation Attribute**

* Define which attribute correlates subprocess results with parent data
* This determines whether results **update existing** or **insert new** array elements

#### Correlation attribute behavior

When subprocess results return, the correlation attribute determines how data is handled:

> [card] Update Existing
>
> When the correlation attribute value **matches** an element in the parent array, that element is updated with the subprocess result.

> [card] Insert New
>
> When the correlation attribute value **doesn't match** any element in the parent array, the result is inserted as a new element.

#### Example: Processing shipping codes

**Scenario**: Process multiple shipping codes in parallel, determining package type for each.

**1. Prepare Parent Process Data**

Create an array of shipping codes using a business rule:

```java theme={"dark"}
import java.util.*;

def mapValues(shippingCode) {
    return {
        "shippingCode": shippingCode
    }
}

shippingCodeList = [];
shippingCodeList.add(mapValues("12456"));
shippingCodeList.add(mapValues("146e3"));
shippingCodeList.add(mapValues("24356"));
shippingCodeList.add(mapValues("54356"));
output.put("shippingCodeList", shippingCodeList);
```

**2. Configure Call Activity**

* Enable **Parallel Multi-instance**
* Set **Input Array**: `shippingCodeList`
* Set **Output Array**: `packageType`
* Set **Correlation Attribute**: `shippingCode`

**3. Map Input Parameters**

* Map `${item.shippingCode}` → subprocess `shippingCode` input parameter

**4. Subprocess Processing**

In the subprocess, process each shipping code:

```java theme={"dark"}
import java.util.*;

map = new HashMap();

if (input.item.shippingCode.startsWith("1")) {
    map.package = "Fragile";
} else {
    map.package = "Non-fragile";
}

map.shippingCode = input.item.shippingCode;
output.put("result", map);
```

**5. Result**

Each subprocess returns its result, which is collected in the parent's output array:

```json theme={"dark"}
{
    "package": "Non-fragile",
    "shippingCode": "54356"
}
```

> [!WARNING]
>
> **Array changes reset mappings**: When you modify the input or output array configuration and save, any existing mappings are automatically deleted. Reconfigure your mappings after changing array definitions.

> [!NOTE]
>
> **Sync mode behavior**: When parallel subprocesses run in sync mode and the parent process token advances (due to another action), unfinished subprocesses are automatically dismissed.

### Workflow integration mapping

Data mappers also connect a process to an [integration workflow](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md): the **Start Integration Workflow** action maps process data to the workflow's declared input parameters, and the Receive Message Task's data stream maps each workflow End node's output back to process attributes. Both sides also offer a **Legacy Mapping** mode that works with a hand-typed body or key instead.

For the mode comparison and the output-mapping configuration steps, see [Legacy mapping vs data mappers](https://docs.flowx.ai/6.x/docs/building-blocks/node/message-send-received-task-node.md#legacy-mapping-vs-data-mappers) on the Receive Message Task page.

The **Start Integration Workflow** action maps process data into the workflow's input parameters:

![Start Integration Workflow action on a Send Message Task, showing the input mapping panel for the selected workflow](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/cookbooks/cb-ext-api-05-send-action.png)

The Receive Message Task's data stream maps each workflow End node's output back to process attributes:

![Receive Message Task Integration Output panel with Source set to Workflow, a selected workflow, and the output mapping for the End and End failure nodes](https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/cookbooks/dst_wkflw_workflow.png)

## Transforming arrays

When a parameter is an array, the data mapping panel maps it **wholesale**, you cannot map individual elements or sub-attributes from the UI. To filter, reshape, or compute over an array, switch to **function mode** by clicking the **f(x)** icon next to the parameter and use JavaScript on the resolved value.

> [!WARNING]
>
> The `${...}` interpolation syntax resolves a **path** to its value, it does not evaluate JavaScript inside the braces. Method calls like `${application.documents.filter(...)}` will fail. Place the placeholder first, then chain methods on the result.

**Default mapping** (pass the array through, no transformation):

```js theme={"dark"}
return ${application.documents};
```

**Filter an array**, keep only documents with `id` equal to 1:

```js theme={"dark"}
return (${application.documents} || []).filter(doc => doc?.id === 1);
```

**Map to a new shape**, extract a single field from each element:

```js theme={"dark"}
return (${application.documents} || []).map(doc => ({ documentId: doc.id }));
```

**Combine filter and map**:

```js theme={"dark"}
return (${application.documents} || [])
  .filter(doc => doc?.status === "APPROVED")
  .map(doc => doc.id);
```

> [!TIP]
>
> Always default to `|| []` when chaining array methods on a placeholder. If the source path resolves to `undefined` (parameter not yet populated), `.filter()` and `.map()` would throw, the empty-array fallback keeps the mapping safe.

## Testing and validation

### Testing methodology

**1. Use Example Values**

* Use example values from your data model for testing
* No need for separate mock data
* Values automatically populate in test scenarios
* **Auto-populate benefit**: Example values help visualize attribute meaning and expected data

**2. Test Payload Generation**

* Click "test" button to visualize JSON payload
* See exactly what data will be sent to destination component
* Verify transformations work as expected
* **Display formats**: View results as schema or JSON for better understanding

**3. Variable Mapping Validation**

* Verify interpolation syntax `${variableName}` is correctly formatted
* Test both manual mappings and auto-populated ones
* Ensure data type compatibility between source and destination

> [!NOTE]
>
> The interpolation format `${variableName}` used in Data Mappers differs from process key formats. Pay attention to this when manually entering variable paths.

**4. Apply Previous Session Information**

* Use information from previous sessions in testing
* Validate real-world scenarios
* Ensure data flows correctly end-to-end

**5. Testing subprocess data**

* When testing data coming from subprocesses, you need to check for the UUID instance of the subprocess and copy paste it in the instance field of the test data, as shown in the demo below:

<video controls autoPlay src="https://s3.eu-west-1.amazonaws.com/docx.flowx.ai/5.x/test_data_mappers.mp4" />

### JavaScript transformation testing

> [accordion] Syntax Requirements
>
> * All computed values must include `return` statements
> * Use clear parameter notation (e.g., `userVerification.status`)
> * Functions must handle potential undefined values

> [accordion] Error Handling
>
> * System sends data even with type mismatches
> * JavaScript errors trigger for undefined object property access
> * Test transformations thoroughly before deployment

> [accordion] Value Persistence
>
> * Previous values are saved during configuration
> * Only lost upon clicking "confirmation" and "save"
> * Allows iterative testing and refinement

## Managing parameter changes

Different types of parameter changes require different handling - some propagate automatically while others need manual updates.

### Automatic propagation

These changes propagate automatically to input/output parameters and mappings:

> [card] Deleted Attributes
>
> **Automatic removal**: When you delete an attribute from the data model, it disappears from input/output parameters and mappings

> [card] Renamed Attributes
>
> **Automatic update**: When you rename an attribute in the data model, the change reflects in input/output parameters and mappings

### Manual intervention required

> [card] New Attributes
>
> **Manual addition**: When you add new attributes to the data model, you must manually:
>
> 1. Add them to input/output parameters
> 2. Configure them in the data mapper

### Data Model propagation timing

Propagation speed varies by data model type:

> [!NOTE]
>
> When you don't alter data type structure (e.g., adding attributes or changing types), updates propagate as follows:
>
> * **Project data model**: Immediately
> * **Library data model**: After the dependency build is updated

### Best practices for parameter changes

> [!WARNING]
>
> Always test your mappings after any data model changes to ensure they function correctly.

## Use cases

Configure data mappers for these scenarios:

> [accordion] Start Subprocess Action
>
> Mappings can be configured whether the subprocess is triggered from:
>
> * **Call Activity node**: Direct subprocess invocation within process flow
> * **User Task node**: Subprocess triggered by user interaction
>
> Both scenarios support full input and output parameter mapping capabilities.

> [accordion] Subprocess Execution Modes
>
> Data mappers handle different subprocess execution patterns:
>
> * **Synchronous execution**: Parent process waits for completion, enabling both input and output mapping
> * **Asynchronous execution**: Parent process continues without waiting, supporting input mapping only
> * **Single instance**: One subprocess instance per trigger
> * **Parallel multi-instance**: Multiple subprocess instances started simultaneously from an array. See [Parallel multi-instance mapping](#parallel-multi-instance-mapping) for detailed configuration.

> [accordion] Reusable UI Template Integration
>
> When integrating a pre-defined reusable UI template into a User Task node:
>
> * Map data from parent process to template input parameters
> * Configure template output to flow back to parent process
> * Enable consistent UI behavior across multiple processes

## Real-world examples

### Example 1: Monthly income collection

**Scenario**: A subprocess collects monthly income information from users and passes it back to the parent process.

**1. Subprocess Design**

* **UI Behavior**: Modal appears asking user to select currency and enter income amount
* **Data Collection**: User enters monthly income value
* **Requirement**: Pass collected data back to parent process

**2. Data Model Configuration**

**In the subprocess**:

* Add `monthlyIncome` variable to the data model
* Navigate to **Output Parameters** tab
* Define `monthlyIncome` as an output parameter

**In the parent process**:

* Initially no input parameters needed (not sending data to subprocess)
* Focus on receiving output data

**3. Call Activity Mapping**

* Open the **call activity** node in parent process
* Navigate to **Input and Output Parameters** section
* **Output mapping**: Connect subprocess output to parent process variable

**Variable format**: Use `${monthlyIncome}` (interpolation syntax)

> [!TIP]
>
> **Auto-mapping shortcut**: Select data model types from dropdown to automatically populate mappings instead of manual entry.

**4. Variable Renaming Example**

* **Subprocess variable**: `monthlyIncome`
* **Parent process variable**: `incomePerMonth` (renamed for clarity)
* **Mapping**: `${monthlyIncome}` → `incomePerMonth`
* **Result**: Two distinct data models successfully connected

### Example 2: Time-off approval with JavaScript transformation

**Scenario**: A colleague submits a time-off request, requiring approval with enhanced data transformation.

**1. Request Flow Design**

* **Input data**: Start/end dates, requester information
* **UI Behavior**: Modal shows request details with approve/deny options
* **Output requirement**: Return approval status + approver name

**2. Input Parameter Mapping**

* **Parent process sends**:
  * Approver name
  * Request details (start date, end date)
* **Subprocess receives**: Input parameters for display

**Configuration**: Parent process output parameters → Subprocess input parameters

**3. JavaScript Transformation for Output**

**Goal**: Combine approval decision with approver identity

* Click the **function icon** next to the output variable
* **Script example**:

```javascript theme={"dark"}
return ${approverName} + " approved on " + new Date().toISOString()
```

**Dynamic value syntax**:

* Use `${variableName}` to reference dynamic values: `${approverName}`

> [!WARNING]
>
> Always include `return` statements in JavaScript transformations.

**4. Testing Transformation**

* Click **test** button to preview transformed output
* Verify JavaScript logic with example data
* **Result**: Enriched data flows back to parent process

> [!NOTE]
>
> **Key Takeaway**: Data Mappers enable not just data transfer, but also data enrichment and transformation through JavaScript, making them versatile tools for complex business workflows.

## Best practices

> [card] Define Data Models Early
>
> Establish project and library data models before creating processes for maximum reusability

> [card] Use Example Values
>
> Include meaningful example values in data models to improve testing and configuration experience

> [card] Plan for Reusability
>
> Design data structures that can be shared across multiple components and processes

> [card] Test Thoroughly
>
> Validate mappings and transformations with various data scenarios before deployment

> [card] Document Dependencies
>
> Note any dependencies between mapped parameters and transformation logic

> [card] Use Quick Mapping
>
> Use quick mapping for components with identical data types to speed up configuration

## FAQs

> [accordion] Do parameter changes propagate automatically?
>
> **It depends on the change type**:
>
> * **Deleted attributes**: Automatically removed from mappings
>
> * **Renamed attributes**: Automatically updated in mappings
>
> * **New attributes**: You must manually add and configure them
>
> > [!WARNING]
> >
> > Always test your mappings after making parameter changes to ensure they still function correctly.

> [accordion] How do data mappers impact subprocess configuration?
>
> When you start a subprocess using Data Mappers:
>
> * **No need to configure "Append Data to Parent Process" action** in the subprocess anymore
> * For **synchronous subprocesses**: Output automatically flows back to parent process
> * For **asynchronous subprocesses**: You can configure input mapping, and the subprocess can append data back to the parent process asynchronously

> [accordion] How do you set up process parameters with multiple end nodes?
>
> You can define input and output parameters for each end node separately:
>
> * Navigate to **Data Model** → **Input/Output Parameters**
>
> * Select the specific node from the dropdown
>
> * Configure parameters independently for each end node
>
> > [!NOTE]
> >
> > Use this for processes with exclusive gateways where different entry points need different data structures.

> [accordion] What happens with currency variables in input mapping?
>
> **Known limitation**: When you send a currency variable with amount and code as input, the system doesn't transmit the code because inputs don't collect the code from currency fields.
>
> **Solutions**:
>
> * Set the code as optional in the output parameters, OR
>
> * Gather the code separately using a segmented button or other input method
>
> > [!WARNING]
> >
> > Handle this properly to avoid mapping errors.

## Current limitations

Current limitations to be aware of:

> [accordion] Start Subprocess for collection item
>
> * **Array to Object Mapping**: Cannot map array → object for scenarios when you edit or add an item in a collection *(estimated fix: 5.X Feature)*

> [accordion] Currency variable input mapping
>
> * **Currency Code Transmission**: When mapping currency variables as input, only the amount is sent - the currency code is not transmitted
> * **Workaround Required**: Either make code optional in output parameters or collect currency code through separate input methods

## Related documentation

> [card] [Call Activity Node](https://docs.flowx.ai/6.x/docs/building-blocks/node/call-subprocess-tasks/call-activity-node.md)
>
> Learn about call activity nodes and subprocess execution

> [card] [Integration Designer](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/integration-designer.md)
>
> Discover workflow automation and external system integration

> [card] [Data Model](https://docs.flowx.ai/6.x/docs/building-blocks/process/data-model.md)
>
> Understand process data structure and management


## Related topics

- [FlowX.AI 5.1.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.1.x-lts/v5.1.0-october-2025/v5.1.0-october-2025.md)
- [FlowX.AI 5.0.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.0.0-july-2025/v5.0.0-july-2025.md)
- [Workflow data model](https://docs.flowx.ai/6.x/docs/platform-deep-dive/integrations/workflow-data-models.md)
- [Passing data between nodes](https://docs.flowx.ai/6.x/docs/building-blocks/process/passing-data-between-nodes.md)
- [FlowX.AI 5.3.0 Release Notes](https://docs.flowx.ai/release-notes/v5.x/v5.3.0-december-2025/v5.3.0-december-2025.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.