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.
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 Event History for traceability.
Verification
Create a test ticket that matches your filters. Confirm the workflow appears in Event History, 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.
Ticket dispatch
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.
Ticket merge
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.
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
Gotchas and tips
Avoid race conditions
Avoid race conditions
When multiple workflows target the same field, set clear ordering and use conditions to prevent ping-pong updates.
Idempotency matters
Idempotency matters
Design actions so re-running them is safe. Use markers like labels or comments to detect previous runs.
Narrow filters before expanding
Narrow filters before expanding
Start with a tight scope (specific queue or company) to validate. Expand only after consistent results.
Handling missing data
Handling missing data
If required fields are absent, prefer commenting and requesting info rather than failing silently.
Visual confirmation
