> ## Documentation Index
> Fetch the complete documentation index at: https://docs.theymes.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Actions and Switches

> Actions are the steps an automation runs after its trigger. Each action can use static values or Liquid variables from the trigger and previous actions.

Actions are the steps an automation runs after its trigger. Each action can use static values or Liquid variables from the trigger and previous actions.

## Core actions

| Action | What it does |
| - | - |
| HTTP request | Calls an external API with a configurable method, URL, headers, credentials, body, and outputs. |
| Send Slack message | Sends a message to a Slack channel. |
| Set variables | Creates named variables from Liquid templates for later actions. |
| Generate with AI | Sends a Liquid system prompt to AI and stores the model output as a variable. |
| AI Switch | Uses AI to select the branch that best matches templated input. |
| Switch | Routes the automation through the first branch whose condition matches. |

## Ticket actions

Ticket actions are available in manual ticket workflows and other automation types that can access tickets.

| Action | What it does |
| - | - |
| Set ticket tags and fields | Adds tags and custom fields to a ticket. |
| Remove ticket tags and fields | Removes tags and custom fields from a ticket. |
| Send message | Sends a message to the customer. |
| Add private note | Adds an internal note to the ticket. |
| Put ticket on hold | Puts the ticket on hold. |
| Remove ticket from on hold | Removes the ticket from on hold. |
| Assign ticket | Assigns the ticket to a user or unassigns it for automatic assignment. |
| Close ticket | Closes the ticket with a resolution. |

### Ticket message status

The **Status after sending** setting provides three modes:

* **Automatic** uses the normal ticket status transition. If the automation sends the first agent-side message, it becomes the ticket's entry message and does not normally change the status.
* **Force waiting** removes any existing hold, moves the ticket to Waiting, and starts its waiting timer when the message is sent. This is useful when an automated entry message asks the customer to respond.
* **Keep current** sends the message without changing the ticket's current status or waiting timer.

### Status after removing hold

The **Status after removing hold** setting provides three modes:

* **Automatic** restores the status based on the ticket's latest messages and assignment history.
* **Force waiting** moves the ticket to Waiting.
* **Force assigned** moves an assigned ticket to Assigned. If the ticket has no assignee, it moves to Unassigned instead.

### Ticket assignment status

The Assign ticket action's **Match status to assignment** checkbox is unchecked by default.

* **Unchecked (Automatic)** keeps Waiting, On hold, and Closed unchanged. Otherwise, status follows the new assignment.
* **Checked** sets Assigned when an assignee exists, or Unassigned when there is no assignee, even if the ticket is Waiting. On hold and Closed remain unchanged.

Use **Unassign** with **Match status to assignment** checked to return a Waiting ticket to Unassigned so it can be considered for automatic routing. An empty dynamic assignee value also unassigns the ticket. This setting does not remove holds, reopen closed tickets, or reset waiting timers.

Existing nodes without this setting use Automatic. To enable the override, check **Match status to assignment** and publish an updated automation version.

### Assign to an AI agent

The **Assign ticket** action can also assign an [AI agent](/product/ai-agents/overview.md). Select the agent as the assignee and make sure it is Ready and enabled for the ticket's app. Automations can assign agents even when **Hide from assignee menu** is on.

See [AI agent assignment strategies](/product/ai-agents/assignment.md) for trigger routing, manual workflows, and human handoffs.

## HTTP requests

Use an HTTP request action to send data to an external service or retrieve data for later actions.

The HTTP request action supports:

* Methods: `GET`, `POST`, `PUT`, `PATCH`, and `DELETE`.
* Liquid variables in the URL, headers, and body template.
* JSON or raw request bodies for methods that support bodies.
* Bearer token or basic auth credentials.
* Outputs extracted from the response.

### HTTP outputs

HTTP outputs turn response data into variables that later actions can use.

Each output has:

| Field | Description |
| - | - |
| Name | The variable name to create. |
| Type | The expected value type: string, number, boolean, object, or array. |
| Value | How to find the value in the response. |

For response paths, use dot notation. For example, `data.name` reads the `name` property from the `data` object in the response.

You can also let AI fill an output value by describing what should be extracted from the response. AI-filled outputs on an HTTP Request step use 1 automation credit in total, regardless of how many AI outputs are configured. Path-based outputs do not use credits.

## Set variables

Use Set variables to create one or more named values from Liquid templates. Later actions can read those values from this node.

Each variable has:

| Field | Description |
| - | - |
| Name | The variable name to create. |
| Type | The expected value type: string, number, boolean, object, or array. |
| Value | A Liquid template that is rendered when the action runs. |

String values are stored as the rendered text. Number and boolean values are parsed from the rendered text. Object and array values must render as valid JSON.

For example, a string variable named `greeting` on a node named `setVariables` can be used later as:

```liquid theme={null}
{{ setVariables.greeting }}
```

For object and array variables, write JSON in the template. Use the `json` filter when inserting object or array values from earlier actions:

```liquid theme={null}
{
  "app": "{{ trigger.app }}",
  "customerId": "{{ trigger.customerId }}",
  "metadata": {{ lookupCustomer.data | json }}
}
```

## Generate with AI

Generate with AI renders a Liquid **System prompt** against the automation context, sends it to the model, and stores the model output as a variable. Each run uses 1 automation credit, the same credit as an HTTP Request step that uses AI-filled outputs. The model is not configurable yet.

For example, a node named `aiGenerate` stores the model output as `result`:

```liquid theme={null}
{{ aiGenerate.result }}
```

## AI Switch

AI Switch classifies text and follows the best matching branch. It consumes **1 automation credit** per successful decision, including fallback selections.

Set **Routing instructions** to explain how to choose, and **Input** to a Liquid template containing the text to classify. Give each branch a label and a description explaining when it applies. Branch order controls display only; AI compares all branches rather than checking them in priority order.

Configure 2–255 choices in total, counting fallback as one choice. Without fallback, use 2–255 branches; with fallback, use 1–254 branches.

Enable **Use fallback branch** to select Otherwise when none of the descriptions fits. Without fallback, AI chooses one of the configured branches. An unconnected selected branch ends execution.

Run history records the selected branch, confidence, and per-branch probabilities with branch IDs and labels. Confidence is informational and does not change routing. Refusals, API failures, and safety-check failures stop the step; they do not select fallback or consume an automation credit.

For example, classify `{{ trigger.issueSummary }}` into **Billing** (payment and refund requests) or **Technical** (crashes and bugs), with an optional Otherwise route for unrelated requests.

### AI prompt safety

AI Switch checks its rendered Liquid input before sending it to the model. Its admin-managed routing instructions and branch details are not checked. Safety checks block prompt attacks and mask email addresses, phone numbers, and payment card numbers. If a check blocks the prompt or is unavailable, the step stops before calling the model or charging an automation credit.

## Switches

A Switch routes an automation into branches.

Each branch has:

* A label.
* An optional description.
* A Liquid condition.
* A connected next action.

Branches are checked in priority order. The first branch whose condition matches is followed. If no branch matches, the fallback branch is followed when one is configured.

Switches also create variables for later actions, such as the selected branch label and whether the fallback branch was used.

## Best practices

* Keep each action focused on one task.
* Use clear node names, because node names are used in Liquid variable paths.
* Add filters or switch branches before actions that change tickets.
* Use run history to verify outputs from HTTP requests, set variables, and summaries before depending on them in later actions.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.