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

# Transform step

> Reshape data into a named, typed object and keep the workflow going.

The Transform step builds a structured, typed object from expressions and records it under the step's name, so later steps can reference the result. Unlike the [Output step](/workflows/steps/output), it is **not terminal** — execution continues to the next step.

## What it does

* Evaluates the expression in each field against `ctx`
* Type-casts each value to the field's declared type
* Records the resulting object under the step's name
* Continues to the next step (it does **not** set the workflow's return value)

Think of it as an Output step you can put in the middle of a workflow: it produces a clean, named payload without ending the run.

## Transform vs Output

|                                | Transform                       | Output                  |
| ------------------------------ | ------------------------------- | ----------------------- |
| Terminates the path            | No — continues to the next step | Yes                     |
| Sets the workflow return value | No                              | Yes                     |
| Result location                | `ctx` under the step's name     | Workflow output + `ctx` |
| Can have steps after it        | Yes                             | No                      |

The two share the same field editor (name, type, value), so a Transform is easy to promote to an Output later, or vice-versa.

## Fields

Each field has:

* **Name** — the key on the produced object
* **Type** — `string`, `number`, `boolean`, `array`, or `object`
* **Value** — a literal or expression resolved against `ctx`

You can edit fields one at a time in the **Fields** tab, or switch to the **JSON** tab to define them all at once as `{ "field": { "value": "{{ expr }}", "type": "string" } }`.

## What lands in ctx

After the step runs, its fields are recorded as a flat object under the step's name:

```json theme={null}
{
  "n5": {
    "customer_name": "Alice Chen",
    "tier": "gold",
    "is_vip": true
  }
}
```

Reference the fields downstream just like any other step:

```
{{ n5.customer_name }}
{{ n5.is_vip }}
```

## When to use it

* **Reshape and rename** — turn a verbose API response into a small, clearly-named object for the rest of the workflow.
* **Consolidate** — combine fields from several upstream steps into one payload you reference in one place.
* **Normalize types** — coerce a stringy value into a real `number` or `boolean` before a Condition step.

### Example: clean up an API response

Given an HTTP step `n4` that returned a large CRM record, a Transform step can distill just what downstream steps need:

```json theme={null}
{
  "name":  { "value": "{{ n4.body.first_name & ' ' & n4.body.last_name }}", "type": "string" },
  "tier":  { "value": "{{ n4.body.subscription.tier }}", "type": "string" },
  "is_vip":{ "value": "{{ n4.body.subscription.tier = 'gold' }}", "type": "boolean" }
}
```

Downstream steps then reference `{{ n5.name }}`, `{{ n5.tier }}`, and `{{ n5.is_vip }}` instead of digging back into the raw response.

## Considerations

* **Pure expressions preserve types.** `{{ n4.body.balance }}` in a `number` field stays a number. A `number` field whose expression resolves to non-numeric text will fail the type-cast — keep the declared type and the value in sync.
* **It doesn't terminate.** Remember to connect a Transform to a following step; on its own it produces data but returns nothing to the caller.