> ## Documentation Index
> Fetch the complete documentation index at: https://docs.morf.health/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Passing Data Between Actions

> Use a fetch action's result object key to feed its data into downstream actions, filters and templates.

## What is a result object key?

A [fetch action](/docs/libraries) retrieves data from a third-party tool, such as a Healthie user or a list of available appointment slots. Every fetch action has an **Object Name**, and the data it returns is stored under that name for the rest of the workflow run. Any node downstream of the fetch action can read from it.

The object name is the key you'll see in the field picker and write in CEL expressions, so choose something short and descriptive, like `healthie_user` or `open_slots`.

## Setting the object name

1. Select the fetch action node and open its configuration panel.
2. Enter a name in **Object Name**. Spaces become underscores and anything other than letters, numbers and underscores is dropped.
3. Save the workflow.

Morf generates a default name from the application and action, such as `healthie_v1_get_user_result_0`. Renaming it early is worth the few seconds, because downstream nodes reference the name directly.

<Warning>
  Object names must be unique within a workflow. Renaming an object name after downstream nodes reference it breaks those references, which will show as validation errors on the downstream nodes until you update them.
</Warning>

## Using the result downstream

### In the field picker

When configuring a destination action, fetch action or profile update below the fetch, the field picker shows a section for each upstream result, labelled with its object name. The trigger's own fields stay under **Payload Field**. Pick a field from the result's section and Morf writes the reference for you.

### In CEL

Reference a field as a dotted path starting with the object name:

| Expression | Meaning |
| - | - |
| `healthie_user.first_name` | a top-level field of the result |
| `healthie_user.location.zip` | a nested field |
| `open_slots.slots[0].start_time` | the first element of a list |
| `open_slots.slots.map(s, s.start_time)` | every element's field, as a list |
| `size(open_slots.slots) > 0` | whether the list has any entries |

The same expressions work in filter nodes, wait conditions and calculated values. The fields available under each object name are listed in the **Result Object Field Details** section of each fetch action's page in the [action library](/docs/libraries).

## When the result might be missing

A fetch action's result is only present if the node actually ran and succeeded. Two settings affect that.

### Missing parameters

If the fetch action's **Advanced Settings** set the missing-parameter behaviour to **Skip node**, the node is skipped when an input is missing and no result is produced. Morf then treats the result as optional downstream, and a plain reference like `healthie_user.first_name` fails on runs where the node was skipped.

Use the optional form so the expression degrades gracefully:

| Expression | Result when the node was skipped |
| - | - |
| `healthie_user.?first_name` | `optional.none()` |
| `healthie_user.?first_name.orValue("")` | `""` |
| `healthie_user.?first_name.hasValue()` | `false` |

The field picker writes the optional form for you when the fetch node is configured this way. See the [Custom JSON Payloads](/docs/events/payloads/morf/json_body#missing-keys-and-optionals) page for more on how optionals behave.

### Failures

If the third-party call fails, downstream nodes on that branch don't run, so they never see a missing result. To keep going after a failure, turn on **Continue when this action fails** in the node's Advanced Settings and split the downstream path with `parentActionErrored()` as described in [Error Branching](/docs/knowledge_base/error_branching). On the error branch the result is absent, so don't reference it there.

## Example: enrich a form response with Healthie data

1. **Trigger** on a Formsort form response.
2. **Profile lookup** to match the respondent to a Morf profile.
3. **Fetch action** Healthie `Get User`, with object name `healthie_user`.
4. **Destination action** Slack `Send Message`, with a message that uses both sources: the respondent's first name from the form response, and their provider from `healthie_user.provider_name`.

Because the Slack node sits below the fetch, `healthie_user` appears in its field picker as its own section, alongside the form response's fields under **Payload Field**.


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