Actions

An action is a step that does something in a connected tool: create a record, send a message, update a contact. An automation can have as many actions as you need, and they run in order.

Configuring an action

Each action has its own fields, defined by the tool it belongs to. Some are required, some optional. Field types vary — plain text, numbers, dates, checkboxes, and dropdowns that load real options from the connected tool, so you pick an actual database or channel rather than typing an identifier.

Every field can take its value in one of two ways:

• A fixed value you type in once. Use this when the value never changes — always posting to the same channel, always tagging with the same label.
• A value from an earlier step. Use this when the value comes from whatever triggered the automation — the customer's email, the order total, the form answer.

Mixing them is normal: a fixed database, a mapped title, a fixed status.

Using data from earlier steps

Any step can use output from any step before it, not only the trigger. If an action creates a record and returns its ID, a later action can use that ID.

This is why fetching a trigger sample first matters — it gives you the real field names to map from.

Chaining actions

Actions run in sequence, and each one waits for the previous to finish. If a step fails, the run stops there and is recorded as failed, so later steps do not run against incomplete data.

To run different actions in different circumstances, put a filter or branch in front of them.

Reusing a set of steps

If the same sequence appears in several automations, build it once as its own automation and call it as a sub-automation. The calling automation passes data in, the sub-automation runs, and control returns to the parent.