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.
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, andDELETE. - 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:
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 namedaiGenerate 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.
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.