Map Step

The Map step builds one new value out of data the run already has. You give it a JSON object — the Mapping Path — in which any string beginning with $. is a JSONPath expression. Every expression is resolved against the flow’s data, and the finished object becomes the step’s result. That is the whole step. Map runs no code, calls nothing, and makes no decisions.

Map rewrites data you already hold. If the change needs logic — arithmetic across a list, conditionals, parsing — use the Eval step instead.

Configuration

The Map editor has three tabs:

Tab	Contents
General	Step name and step ID
Payload	Mapping Path — the JSON mapping object. Required.
Testing	Test Data plus a Run Test button that resolves the mapping against that sample

The Mapping Path field holds the object to build, as JSON. Values that begin with $. are read as JSONPath; everything else is copied through unchanged. There are no other settings. There is no transform type to choose, no per-item mode and no code field.

Writing a mapping

"$.STEP_ID.field" reads a value from a completed step.
The data available to a mapping is trigger (the payload that started the run), static, env, and one key per completed step, named with that step’s ID.
Any other string, number, boolean, array or nested object is copied through exactly as written.
A key may itself be a JSONPath expression — it is replaced by the value it resolves to.
A | character joins segments into a single string, mixing literal text with resolved values.

A worked example

With this data in the run:

{
  "trigger": {
    "customer": { "name": "Dana Reyes", "email": "dana@example.com" },
    "items": [
      { "sku": "A-1", "qty": 1, "price": 20 },
      { "sku": "B-2", "qty": 3, "price": 5 }
    ]
  },
  "GET_ORDER": { "status": 200, "data": { "id": "ord_88", "total": 35, "currency": "usd" } }
}

this Mapping Path:

{
  "name": "$.trigger.customer.name",
  "first_sku": "$.trigger.items[0].sku",
  "all_skus": "$.trigger.items[*].sku",
  "order": "$.GET_ORDER.data",
  "summary": "Order |$.GET_ORDER.data.id| for |$.trigger.customer.name",
  "channel": "web"
}

produces:

{
  "name": "Dana Reyes",
  "first_sku": "A-1",
  "all_skus": ["A-1", "B-2"],
  "order": { "id": "ord_88", "total": 35, "currency": "usd" },
  "summary": "Order ord_88 for Dana Reyes",
  "channel": "web"
}

Numbers and booleans keep their type; only | concatenation turns a value into text.

A resolved key

A JSONPath key is resolved the same way, so a mapping can be keyed by a value from the run:

{ "$.trigger.customer.email": { "total": "$.GET_ORDER.data.total" } }

{ "dana@example.com": { "total": 35 } }

Two behaviours worth knowing

A path that matches nothing resolves to an empty array, not null. "$.trigger.nope" becomes []. A step reading that value downstream sees an empty array, so test for it with Array.isArray(x) && x.length === 0 rather than for a missing key.

A multi-match expression collapses to a single value when only one item matches. "$.trigger.items[?(@.price>1)].sku" returns ["A-1", "B-2"] above, but "$.trigger.items[?(@.qty>2)].sku" returns the bare string "B-2". Anything downstream that expects a list must cope with both shapes.

Referencing the result

The mapped object is stored flat under the step’s ID. If the step ID is map_1:

$.map_1.name
$.map_1.order.total

There is no .output or .result wrapper.

Testing a mapping

Open the Testing tab, paste a sample of the flow data into Test Data, and click Run Test. The same resolver that runs inside a flow is used, so the result you see is the result the step will produce.

Editing a flow changes its draft. A change only affects the live flow once you Publish it. Save keeps your work; Publish makes it take effect.

What the Map step does not do

Map is deliberately narrow, and several things it is often expected to do belong to other steps:

It does not iterate. There is no per-item execution, no fan-out and no item variable. A JSONPath expression can select many values at once, but the step still runs once and produces one result.
It does not filter a list into separate runs. A filter expression narrows the values it reads; it does not start a run per match.
It does not run JavaScript. Use the Eval step.
It does not branch or route. Use the Condition step.
It cannot fail over to an error path. A mapping that cannot be resolved errors the step and ends the run.

What runs next is decided by a Condition step’s outcome, not by the arrows in the editor. A condition’s outcome names the step IDs to run — one, several (they start at the same time), or the reserved RESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names is decoration, and an outcome naming a step that is not in the flow fails the run with next step not found.

Next Steps

Variable Mapping

JSONPath reference for every step

Eval Step

JavaScript for logic Map cannot express

Condition Step

Decide which step runs next

Functions Step

Built-in operations for common tasks

Get Started

Spaces

Meetings

Forms

Assistants

Collaboration

Flows

Account Management

Advanced

Developers

Map

Map Step

Configuration

Writing a mapping

A worked example

A resolved key

Two behaviours worth knowing

Referencing the result

Testing a mapping

What the Map step does not do

Next Steps

Variable Mapping

Eval Step

Condition Step

Functions Step

​Map Step

​Configuration

​Writing a mapping

​A worked example

​A resolved key

​Two behaviours worth knowing

​Referencing the result

​Testing a mapping

​What the Map step does not do

​Next Steps

Variable Mapping

Eval Step

Condition Step

Functions Step

Map Step

Configuration

Writing a mapping

A worked example

A resolved key

Two behaviours worth knowing

Referencing the result

Testing a mapping

What the Map step does not do

Next Steps