Skip to main content
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

Ticket actions

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

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. 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 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: 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: 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:
For object and array variables, write JSON in the template. Use the json filter when inserting object or array values from earlier actions:

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:

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.