Skip to main content

​
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.
Ticket created trigger configuration

Examples of ticket-based triggers

​
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

1

An event occurs

Your PSA emits an event (for example, ticket created). NeoAgent receives the event.
2

Filters apply

Deterministic rules run first, then optional AI filters. If an item matches, the workflow proceeds.
3

Actions execute

Actions run in order. Use safe ordering (validate, comment, then modify fields) to reduce risk.
4

Results recorded

Outputs and any errors appear in Executions for traceability.

​
Verification

Create a test ticket that matches your filters. Confirm the workflow appears in Executions, and the expected actions completed in sequence.

​
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.
Sequential processing is especially important for ticket dispatch and merge operations where timing and order matter.
Here are some examples where sequential processing is beneficial:
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.
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.

​
Execution window

Turn on Restrict execution time windows to let the workflow run only at set times. A trigger event outside those times is ignored.
  • Time windows per day: Each day of the week has its own list of windows, and a day can hold more than one (for example 07:00–12:00 and 13:00–19:00). A day with no windows does not run. A window whose end is earlier than its start, such as 22:00–06:00, covers that day from midnight to the end time and from the start time to midnight; it does not continue into the next day.
  • Copy: The copy button under a day, such as Copy Mon under Tuesday, gives that day the same windows as the day before it. Copy to all gives every day of the week the windows of that day. Set one day, copy it, then change the days that differ.
  • Quick presets: Fill the week with Mon–Fri 9am–5pm, Mon–Fri all day, or weekends all day.
  • Timezone: The timezone that every window follows.

​
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 — any note (public or internal) from any non-Neo author, including customer notes and system/automation notes
  • Technician added a note — a human technician added a note (public or internal). Unlike Note added, this skips customer notes and system/workflow/automation notes (e.g. Autotask workflow rule notes), so it’s the credit-efficient choice for “react when a tech documents work” agents such as automatic time entry. On ServiceNow, only internal work notes fire this trigger — ServiceNow doesn’t record who authored a public comment, so those are left to Technician replied to customer to avoid firing on customer comments
  • Time entry created on the ticket (see Time entry triggers)
On HaloPSA, Ticket created fires on the ticket’s own creation only. When you merge a ticket into another one, HaloPSA copies the merged ticket’s opening entry onto the target, and a new sender’s first email on an existing ticket is logged the same way. Neither fires Ticket created on the ticket they land in. On Autotask, a time entry or an internal note changes only the ticket’s Last Activity Date. Neo therefore subscribes your Autotask ticket webhook to that field when a workflow uses Time entry created, Note added or Technician added a note. Autotask then sends Neo a webhook for every change to a ticket. Neo adds the field at the next scheduled PSA sync, about once a day. Until then a time entry or an internal note fires such a trigger only when another change to the ticket arrives; a customer-visible note fires it as before. Note added and Technician added a note run the workflow at most once per change Neo processes, like every other trigger. Neo records each note it has seen on a ticket, so a later change to the same ticket does not run the workflow again for that note; notes that arrive together share one run. On the first change Neo sees for a ticket, it looks back 24 hours for notes, the same window it uses for every other ticket event.
  • 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. What the agent is told about its trigger. Each run tells the agent which of these events started it, for example “a technician added a note to the ticket” or “the customer replied on the ticket”. It does not say which note or reply started the run, and does not quote it. A trigger that matches while the agent is still running on that ticket. An agent has one run at a time on a ticket, and Neo starts no second run while it runs. Two triggers reach the running agent instead: Customer replied, and Ticket updated narrowed to a field, such as Status changing to a value you picked. The running agent takes one more pass when its current pass ends, reads the ticket again, and sees the reply or the new field value. So a ticket that leaves a status and comes back while the agent waits still gets handled. Executions shows this as the same run, which ends later. A field change gives a run at most one extra pass. On ConnectWise, Autotask, HaloPSA and Syncro, a field change the agent made itself through its PSA tool gives none; a change from a script the agent ran, or any change on ServiceNow, can still give that one pass. An agent with Run Agent only once per ticket on takes no extra pass, and a workflow of fixed actions takes none for a field change. Any other trigger that matches while the agent runs on the ticket starts nothing, and the running agent sees that change only if it reads the ticket after it. With Process entities sequentially on, none of this applies: each match queues a new run, which starts after the current run ends.

​
Narrowing a Ticket updated trigger to specific values

When you narrow Ticket updated to a standard field, From value and To value limit the trigger to specific values of that field. Leave either blank to match any value. Add more than one value to match any of them. Pick from the dropdown, or type a value and press Enter. Type the value exactly as your PSA shows it; matching ignores upper and lower case. Type it in when your PSA uses a value the dropdown does not list. On ServiceNow, the Status dropdown covers the states of every ticket type — incident, request, request item (RITM), task, change request and problem. Request items use their own states, such as Work in Progress and Awaiting Approval.
What counts as a customer reply on ConnectWise. ConnectWise records a customer’s reply and a technician’s own client-facing note in the same way, so Neo pairs the event with the note behind it before firing. The note has to be one ConnectWise attributes to a contact.A reply from an address that is also a ConnectWise member is attributed to that member, which makes it a technician note, so Customer replied does not fire for it. That is ConnectWise’s own classification, and it is what keeps a technician’s note — and Neo’s own reply — from starting the agent again. It surprises people testing from their own work mailbox: see Testing an agent before you trust it.Replies from senders ConnectWise holds as neither a contact nor a member, such as a colleague copied into the thread, are a separate setting: Replies from unregistered contacts. It is on the trigger, not on the ConnectWise integration page. Open the agent’s Triggers & Filters tab, or a workflow’s Schedule/Select step, and add a Customer replied condition. Below the conditions, next to “In ConnectWise, a reply only counts when the sender is a registered contact”, click Configure, turn on Let these replies trigger your agents and workflows, and save. You can also ask the Neo Support Agent to turn it on or to edit the Exceptions list for you.The switch and its Exceptions list are account-wide: they apply to every ConnectWise agent and workflow, not only the one you opened them from. Turning the switch on also lets other mail on a ticket count as a reply, such as a supplier’s helpdesk auto-acknowledgement, so add those senders to Exceptions. Neo applies the switch when it processes a reply, so a reply it already skipped does not start an agent later.The email that opens a ticket is not a reply. ConnectWise records a ticket’s first note in the same way as a reply, so when a customer’s note is the ticket’s first and was written within 15 seconds of the ticket’s creation, Neo leaves it out and Customer replied does not fire for it. A first customer note written later counts as a reply. To start an agent on new tickets, use a Ticket created trigger.
The trigger event and Filter Ticket settings gate PSA events, not direct hand-offs from another agent. When another agent invokes this workflow with the Trigger or Schedule Workflow tool, the hand-off skips this workflow’s configured trigger event, its Filter Ticket conditions, and its execution window. Only Enabled, Triggered type, and entity type still apply. A workflow set to Manual only can therefore still be invoked by another agent. To control which tickets get handed off, control it on the source agent — see Which target settings apply to a direct invocation.

​
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 and the Configuration reference.
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.

​
Gotchas and tips

When multiple workflows target the same field, set clear ordering and use conditions to prevent ping-pong updates.
Design actions so re-running them is safe. Use markers like labels or comments to detect previous runs.
Start with a tight scope (specific queue or company) to validate. Expand only after consistent results.
If required fields are absent, prefer commenting and requesting info rather than failing silently.

​
Visual confirmation

Event history showing a completed triggered workflow