Actions

An action is a single operation against an external system: create a record, fetch a record, update one, delete one, look one up. When you describe a workflow, Claude picks the right actions based on what you want to happen.

You don't pick action verbs

You describe the outcome, not the operation:

> When a new HubSpot contact is created, look them up in Mailchimp.
  If they exist, update their tags. If not, add them.

Claude translates this into the right combination of operations against each app. You don't think about whether the operation is a create, a find, or an update — Claude does.

What actions can do

Most actions in the catalog cover the common operations a vendor exposes: creating records, fetching them, listing them, finding them by an external identifier (email, name, etc.), updating them, and deleting them.

Some actions cover operations beyond create/read/update/delete: sending an email, running a query, kicking off a job. Whatever the vendor's API supports shows up as an action in the catalog.

Custom fields work everywhere

Vendor objects often have custom fields beyond the standard schema. APIANT supports mapping to and from custom fields the same way it does standard fields. You don't pre-declare anything — Claude discovers what's available when it builds against your account.

Error handling

When you describe a workflow, Claude picks a sensible error policy by default and tells you what it picked. You can override it in plain English:

> If the Salesforce update fails, post the failed record to Slack and continue.

See Ops & Support for tuning errors at scale across many automations.

See also

• Field Mappings — how data flows into action inputs
• Triggers — what kicks off the actions in the first place