Action blocks define the operations an Automation Studio rule actually carries out, such as updating fields, sending alerts, or sending instant messages. Multiple action blocks can be added to a single flow, and they execute in the order you configure them.
Action chaining lets one action rely on the outcome of the action before it. Some actions generate output variables that feed straight into the next action, letting information flow through the process without you having to fetch it again. To make this easier to manage, every action block is automatically given a unique identifier, such as 1, 2, or 3, when you configure it. This identifier is prefixed to that action's output variables, so it's clear which action generated which piece of data when several actions are in the same flow.
Dot walking lets you access fields from related modules without building an additional query or action. While configuring a flow, you can select a module and map its available fields directly. For example, from a Ticket record, you can pull in contact details such as an email address during configuration, making related data available in conditions, actions, and notifications without manually fetching it from another module first.
An IT team uses ticket summaries to help build troubleshooting guides, but the default Zia summary can't be customised to fit their exact format. Instead, they build a flow on the Ticket module triggered by Ticket Created. Action 1 uses Generate Content, with context pulled from the recent thread content, subject, description, status, created time, and product name, and a prompt asking Zia to analyse the ticket and produce a structured internal guide covering Issue Summary, Current Situation, Possible Cases, Information Required, and Recommended Next Action. Action 2 then adds that generated guide as a comment on the ticket. Action chaining passes the Generate Content output straight into Add Comment, and dot walking pulls in fields like Product Name from related records, giving the AI rich context without any extra lookup steps.
When a customer reports a damaged product, a support ticket is created and linked to the existing Logistics record for that order. Manually updating the Logistics record once a replacement is approved is easy to overlook, delaying the replacement shipment. To fix this, a flow triggers on Field Updated with the criteria Ticket Status is changed from In Review to Replacement Approved, and an action block updates the record: it targets the Logistics module using the linked Logistics ID, and sets the Logistics record's status to Replacement Pending. Dot walking pulls in the linked Logistics record automatically, removing the need for manual coordination between the support and logistics teams.