Actions Reference

Actions are the building blocks you add inside:

• Workflows > Steps
• AI Agents > Actions for pre-actions and post-actions
• Notification buttons that run follow-up logic

Each action does one job: call an API, send a message, update a record, run another workflow, or prepare data for later steps.

Not every action is available in every builder. Some actions only make sense in workflows, some are designed for assistant pre-actions or post-actions, and some require an active conversation context.

How to use this reference

Use these pages to answer three practical questions:

1. Which action should I choose?
2. Which fields do I need to fill in?
3. What result can I reuse in a later step?

If you need help writing expressions for dynamic fields, see the CEL Expression Editor.

Reusing results from previous steps

Most actions make data available to later steps. You will usually reference it with step(0), step(1), and so on.

Examples:

• step(0).data
• step(1).status
• step(2).choices[0].message.content

Use Debug all or single-step debugging to inspect the exact output shape before you build conditions on top of it.

Shared execution metadata

When you want to know how a step itself ran, use the nested executionContext object. This keeps runner metadata separate from the action's own outputs.

Common fields:

• step(0).executionContext.status -- running, completed, skipped, or failed
• step(0).executionContext.startedAt
• step(0).executionContext.finishedAt
• step(0).executionContext.safeError.code
• step(0).executionContext.safeError.userMessage
• step(0).executionContext.safeError.retryable
• step(0).executionContext.safeResult

Examples:

• get(step(0), 'executionContext.status') == 'completed'
• get(step(1), 'executionContext.safeError.code') == 'unsupported_media_format'
• get(step(2), 'executionContext.safeResult.reason') == 'condition_false'

safeError and safeResult are sanitized for branching and debugging. They do not include raw stack traces, secrets, or provider payloads.

Some actions already use top-level fields such as step(N).status for their own outputs, for example an HTTP status code. Prefer step(N).executionContext.status when you mean the action outcome itself.

Availability and context

• Use conversation actions only when the current run already has a conversation to work with.
• Use assistant-specific actions only where assistant actions are supported.
• If an action depends on a specific feature, such as conversation memory or a child workflow, make sure that feature is already configured before you rely on the action in production.

Categories

Category	Typical use
AI and assistants	Generate text, send work to another assistant, clear memory, or stop an assistant session
Data	Create, fetch, search, update, delete, or trigger workflows against your company data
Messaging	Send replies to the current conversation or proactively message a client
Integrations	Call external APIs with HTTP requests
Media	Save files to storage and reuse their URLs
Notifications	Alert team members inside AutoTalk
Security	Generate temporary JWT tokens
Session state	Store values for later CEL expressions in the same run

Choosing the right action

• Use Generate LLM response when you want direct model output.
• Use Send message to assistant when you want another assistant to handle the request.
• Use Compose conversation response when you want to reply in the current conversation.
• Use Send message to client when you need to message a specific client directly.
• Use Search company data when you need a list.
• Use Fetch company data when you already know the record you want.
• Use Execute workflow when you want one workflow to call another.

Actions that do not return reusable fields

Some actions are mostly side effects and do not give you a meaningful step result to reuse.

Common examples:

• Clear conversation memory
• Finalize assistant session
• Create employee notification

Use them when you need the effect itself, not a value for later logic.