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

# Triggered workflows

> Trigger a workflow on PSA events (ticket created, status changed, time entry posted), and how custom fields / UDFs work in triggers and filters. Covers multiple triggers via OR, run-once-per-ticket, sequential processing, and business-hours / weekend execution windows.

## What it is

Triggered workflows start automatically when a specific event occurs in your PSA, such as a ticket being created, updated, or closed, or when a time entry is posted. They enable near-real-time automation.

<Frame caption="Examples of ticket-based triggers">
  <img src="https://mintcdn.com/neoagent/67c8YiVlnWW7Df07/images/trigger-ticket-created.png?fit=max&auto=format&n=67c8YiVlnWW7Df07&q=85&s=aca56a9543fd6945cc57d6f9205d1aea" alt="Ticket created trigger configuration" width="2842" height="1150" data-path="images/trigger-ticket-created.png" />
</Frame>

## Common use cases

* Auto-assign new incidents by queue, priority, or keywords
* Route after-hours requests to on-call channels
* Add comments when tickets lack required information
* Enforce required fields when closing tickets

## How it runs

<Steps>
  <Step title="An event occurs">
    Your PSA emits an event (for example, ticket created). NeoAgent receives the event.
  </Step>

  <Step title="Filters apply">
    Deterministic rules run first, then optional AI filters. If an item matches, the workflow proceeds.
  </Step>

  <Step title="Actions execute">
    Actions run in order. Use safe ordering (validate, comment, then modify fields) to reduce risk.
  </Step>

  <Step title="Results recorded">
    Outputs and any errors appear in Event History for traceability.
  </Step>
</Steps>

## Verification

<Check>
  Create a test ticket that matches your filters. Confirm the workflow appears in Event History, and the expected actions completed in sequence.
</Check>

## Configuration options

Beyond selecting the trigger event, you have several options to fine-tune when and how your triggered workflow executes:

### Multiple triggers

You can define multiple trigger conditions for a ticket using the `+ OR` button. For example, a workflow could run if:

* A ticket is created, OR
* Its status changes to "Pending Customer"

### Run once per ticket

Enable this option to ensure a workflow runs only once for each unique ticket, even if the trigger condition is met multiple times for that same ticket. This prevents repeated executions for the same underlying cause on the same ticket.

### Process entities sequentially

Enable this option to process entities (tickets, time entries, etc.) in the order they are received, one by one. This is crucial for workflows where the outcome of processing one entity can affect how subsequent entities should be handled, or where simultaneous processing could lead to conflicts.

<Tip>
  Sequential processing is especially important for ticket dispatch and merge operations where timing and order matter.
</Tip>

Here are some examples where sequential processing is beneficial:

<AccordionGroup>
  <Accordion title="Ticket dispatch">
    When multiple new tickets arrive around the same time, processing them sequentially ensures that the dispatch logic has the most up-to-date information about technician availability and current workload. This prevents scenarios where multiple tickets are assigned to the same technician simultaneously because the system hasn't yet registered the first assignment.
  </Accordion>

  <Accordion title="Ticket merge">
    If two tickets (Ticket A and Ticket B) are created very close in time and are candidates for merging, sequential processing prevents a race condition. Without it, the system might try to merge Ticket A into Ticket B, and simultaneously merge Ticket B into Ticket A, leading to errors or an inconsistent state.
  </Accordion>
</AccordionGroup>

### Execution window

* **Exclude weekends**: Prevent the workflow from running on Saturdays and Sundays
* **Only run during these hours**: Define a specific time window (e.g., 9:00 AM to 5:00 PM) during which the workflow is allowed to execute. If a trigger event occurs outside these hours, it will be ignored
* **Timezone**: Specify the timezone that the "Exclude Weekends" and "Only run during these hours" restrictions should adhere to. This ensures consistent behavior across different geographical locations

## Supported trigger events

A triggered workflow fires on one of a fixed set of PSA events. When you configure a trigger, you choose from:

* **Ticket created**
* **Ticket updated** — any change, or narrowed to a change of one **standard field**: status, priority, board / queue, or ticket type
* **Customer replied** to the ticket
* **Technician replied** to the customer
* **Note added** to the ticket
* **Time entry created** on the ticket (see [Time entry triggers](/core/triggers-and-schedules/advanced-time-entry-triggers))
* **Another workflow finished** — chain one workflow off another

This list is exhaustive: if an event isn't on it, Neo can't trigger on it.

### Custom fields and UDFs are not trigger events

There is no "custom field changed" trigger, and a custom field / UDF cannot be the standard field that narrows a **Ticket updated** trigger — that is limited to status, priority, board / queue, and type.

To act on a custom field, trigger on **Ticket created** or **Ticket updated** and add a **filter condition** on it. Filter conditions match any PSA field by its exact name, including custom fields and UDFs — see [Filter tickets](/core/filter-tickets) and the [Configuration reference](/core/configuration-reference).

<Warning>
  A filter condition checks a custom field's **current value** (for example, `My UDF equals "Yes"`) — it does not detect that the field just changed. A **Ticket updated** trigger with a UDF filter runs whenever the ticket is updated and the UDF currently matches, not only when the UDF itself was the field that changed.
</Warning>

## Gotchas and tips

<AccordionGroup>
  <Accordion title="Avoid race conditions">
    When multiple workflows target the same field, set clear ordering and use conditions to prevent ping-pong updates.
  </Accordion>

  <Accordion title="Idempotency matters">
    Design actions so re-running them is safe. Use markers like labels or comments to detect previous runs.
  </Accordion>

  <Accordion title="Narrow filters before expanding">
    Start with a tight scope (specific queue or company) to validate. Expand only after consistent results.
  </Accordion>

  <Accordion title="Handling missing data">
    If required fields are absent, prefer commenting and requesting info rather than failing silently.
  </Accordion>
</AccordionGroup>

## Visual confirmation

<Frame>
  <img src="https://mintcdn.com/neoagent/67c8YiVlnWW7Df07/images/trigger-workflow-finished.png?fit=max&auto=format&n=67c8YiVlnWW7Df07&q=85&s=316b7193801cf3b4fffc3b3eebbd5dbf" alt="Event history showing a completed triggered workflow" width="2854" height="834" data-path="images/trigger-workflow-finished.png" />
</Frame>