> For the complete documentation index, see [llms.txt](https://docs.autommate.com/userguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.autommate.com/userguide/build-automations/configure-actions-and-map-data.md).
# Configure actions and map data
An action performs one operation within a Hyperflow. Its inputs can be fixed values, variables, or data produced by an earlier action. Data mapping connects these pieces without copying values manually between systems.
### Find actions in the editor
The **Action Panel** has **Actions** and **Variables** tabs. The Dublin Work Item editor groups actions under **Add Integration Actions**, **Data Transform Actions**, **Utility Actions**, and **AI actions**, with a Search field.
Open the relevant category and inspect the selected action's inputs and result. The category label is a way to find an action, not a complete description of its behavior.
### Read an action as a contract
Before configuring an action, identify:
| Item | Check |
| --------------- | -------------------------------------------------------------- |
| Operation | Does it read, create, update, delete, or execute something? |
| Connection | Which application and credential will it use? |
| Required inputs | Which fields must be present, and what types do they expect? |
| Result | Which value or record does the next step need? |
| Failure | What should happen if the operation fails or returns no match? |
Use the action reference for the selected application. Similar-looking actions can require different IDs, object structures, or permissions.
### Use Data Manager
Data Manager exposes fields used by actions and helps map data between them. The source action must occur before the action that consumes its output.
1. Add the source action and configure its required connection and input fields.
2. Inspect its response with representative test data.
3. Add the destination action after it.
4. Open Data Manager from the action configuration and locate the required source field.
5. Map that field into the destination input.
6. Check any additional required fields in the destination action.
Data Manager includes field search. Use it to locate the intended field instead of relying on a similar display label. Keep record IDs, names, and free-text descriptions distinct.
### Worked example: assign request data to a String variable
Follow the [request-intake Hyperflow tutorial](/userguide/build-automations/build-a-hyperflow.md) to create a local example. The first data mapping is intentionally small: one fixed text value is assigned to one String variable.
{% code collapsedlinecount="10" %}
```mermaid
flowchart LR
A["Literal text REQ-DEMO-001 | VPN access | Maya Chen"] --> B[String Assign]
B --> C["String variable request_summary"]
```
{% endcode %}
In **Action Control Center**, configure:
| Field | Selection | Role |
| --------------------- | ----------------------------------------- | ------------------------------------------ |
| Value to Assign | `REQ-DEMO-001 \| VPN access \| Maya Chen` | The text the action uses |
| Source to be Assigned | Request summary / `request_summary` | The String variable that receives the text |
Put the sample text in Value to Assign and choose the receiving String variable.
The **Source to be Assigned** label names the receiving-variable selector in this action. Do not reverse the two fields. When using the **+** beside it to create a variable, choose type **string**, name it `request_summary` and select it after saving.
After the manual run, open **Logs Summary → View All Logs**, select the String Assign action details, then **Fetch Input/Output Values → Output**. In this example, **Action Output Type** was **string**, and **Preview** displayed:
{% code collapsedlinecount="10" %}
```
REQ-DEMO-001 | VPN access | Maya Chen
```
{% endcode %}
This is a verified single-action assignment. It does not yet demonstrate two-action mapping or a request-to-ticket integration. When adding a downstream action, select this value using that action's supported field or Data Manager, and inspect the downstream action's actual input before relying on the mapping.
If the required-field indicator remains, check that both the literal and receiving variable are selected. If the variable does not appear, confirm its type and that it belongs to the same flow.
### Example: Xurrent request to Jira issue
The Xurrent request lookup produces data that a later Jira **Create Issue** action can consume. Configure the Xurrent credential and Request ID first. Then configure the Jira credential and project, and map the selected request fields into the relevant issue fields.
This mapping does not make the two products' data models identical. Review mandatory Jira fields and decide what to do when a source value is absent. Test in a suitable project before creating operational issues.
### Transform only what you need
Use transformation actions when the destination expects a different shape or value. **Data Transform** supports selecting a variable or data from an earlier action through **Run and Fetch Data from Action**. Check the source data before invoking an option that may run an action.
Verify the transformed result before passing it to a write operation. Test an empty value, an unexpected type, and a normal value. Keep only fields needed by the destination rather than passing the entire source record by default.
