Actions

An action is a step that does work. Where a trigger decides that a run should happen and a condition decides where it goes next, an action is the part that actually calls a service, transforms a value, changes a piece of content, or tells somebody something. Most of an automation is actions.

Add one by clicking + on an edge and selecting Action, then choosing a type from the panel. The panel groups what is available into the actions that ship with the product and the ones each connected system adds.

Every action type is different in what it does, but they all behave the same way in the flow: they take input, they produce output, and they either succeed or fail. Those three things are what this page is about.

Input

An action gets its input from two places.

Its own fields are the form you fill in—a URL, a message body, a target, an operation. Most fields that take text also accept a variable reference, so the value does not have to be fixed: a subject line can be literal text with the title of the content that triggered the run dropped into the middle of it. The field resolves to its final value just before the step runs.

Input mappings are the general-purpose inlet. Rather than needing a form field for every conceivable input, a step can pull named values from anywhere in the run's vocabulary—any earlier step's output, any variable or secret—and give each one a name. This is how a script step receives structured data to work on, and how any step gets hold of a value that its own fields have nowhere to put.

A step can only reference values that are genuinely upstream of it. A step on one branch of a condition cannot read a step on the other branch, because in any given run only one of them ran.

Output

When an action completes, it publishes an output that later steps can read—the response from a request, the identifier of the thing it created, the list of recipients a message reached.

Most actions declare the shape of that output in advance, which is why the variable picker can show you an upstream step's fields before the automation has ever run. Some outputs have no fields to enumerate—a plain list, a single value, a script result whose shape you did not declare—and those are offered whole rather than piece by piece, so you can forward the entire thing to the next step.

Output mappings work the other way from input mappings: after a step completes, they pull additional values out of what it produced and give them names of their own. Use them to lift a value buried deep inside a large response up to somewhere convenient, so downstream fields reference a short name instead of repeating the same long path.

Failure, retry, and the error path

By default, an action that fails ends the run. Nothing downstream of it runs, and the run is recorded as failed.

Two mechanisms change that.

An error path is a second output on the node, enabled from the node's actions menu. With it in place, a failure routes down the error branch instead of ending the run, so you can notify someone, record what happened, or fall back to another approach. The rest of the flow—the success branch—is skipped exactly as an untaken condition branch is.

Retry handles the failures that are not really failures: a service that was briefly unavailable, a request that timed out once. Steps that call out over the network can be configured to retry with a growing delay between attempts, to give up on a single attempt that runs too long, and to stop hammering an endpoint that has failed repeatedly. Retries survive a restart, and every attempt is recorded, so a step's history shows what it went through rather than only how it ended. Left unconfigured, one failure is final and goes straight to the error path or the run.

The two compose: retry decides whether the step has really failed, and the error path decides what happens once it has. See Building automations for wiring error paths on the canvas, and Monitoring and history for reading a failure afterwards.

Dry run and test overrides

An automation runs in one of two modes. In Live mode, steps act on their real targets. In a dry run, the whole flow still runs—every condition is evaluated, every loop iterates, every step reports what it would have produced—but no real change escapes.

What "no real change escapes" means for a given step depends on whether you have given it somewhere safe to go:

• With a test target configured on the automation, the step's effect is redirected there. The message really is sent, to a test channel; the content really is written, to a sandbox. The step exercises its full path, just not against production.
• With no test target, the step makes no external change at all and logs what it would have done.

Individual steps can carry a test override of their own, which takes precedence over the automation-level target for that step alone—useful when one step in an otherwise safe flow needs to point somewhere different.

Outbound HTTP is the one deliberate exception to "nothing escapes": by default a dry run still sends read-only requests for real, because downstream steps rehearse far more accurately against live response data. See Building automations for the full dry-run policy and how to change it.

The action catalog

This page covers how actions behave. For what each individual action does and every field it takes:

• Actions in the built-in node catalog, for the actions that ship with the product.
• Integrations, for the actions each connected system adds.