Skip to main content
The Trigger or Schedule Workflow tool allows Neo Agent to trigger other configured workflows immediately or schedule them to run at a specific future date and time. It can also schedule the current workflow to re-run itself later.

​
What It Does

When enabled, the agent can:
  • Analyze the ticket and determine if another workflow should be triggered
  • Trigger any of the configured workflows immediately
  • Schedule a workflow (including itself) to run at a future date and time
  • Chain workflows together for complex, time-sensitive automation
Use custom instructions to specify WHEN and WHICH workflow(s) to trigger or schedule. Example: “If the ticket mentions employee termination, immediately trigger the Access Removal workflow and schedule the Account Deletion workflow for 30 days after the last day.”

​
How to Use

  1. Enable the tool and select which workflows can be triggered or scheduled
  2. Provide custom instructions on when to trigger or schedule each workflow
  3. Keep the allowlist focused on workflows you’re comfortable being triggered automatically

​
Example Instructions

​
Triggering Immediately vs. Scheduling

The tool supports two modes based on the situation:

​
Immediate Trigger

When the agent determines a workflow should run right now, it triggers it immediately for the current ticket. You can configure whether the agent should wait for the triggered workflow to complete before continuing.
Run only once per ticket behaves differently on the two immediate-trigger paths, depending on whether the agent waits for the target to finish:
  • Fire and forget (the agent does not wait): if the target has Run only once per ticket enabled and has already succeeded on this ticket, the trigger is skipped and shows as SKIPPED in Executions. The target’s own guarantee holds.
  • Wait for completion (the agent waits for the target to finish before it continues): Run only once per ticket is not enforced. This path starts the target directly and does not go through the same check, so the target can run again on a ticket it has already processed.
This difference is a known behaviour, not a setting you control. If you need the once-per-ticket guarantee to hold in both cases, add your own guard — for example, a filter or an internal note that the agent checks before it triggers the target.
In a chat agent, the agent never waits — “wait for completion” is ignored. Someone is waiting for a reply, and these workflows commonly take six to eleven minutes, so a chat agent always uses the fire-and-forget path. Instead of waiting it tells you what it started and roughly how long that takes, and reads the result afterwards through Get Workflow Run Status (added automatically alongside this tool) so it can report what the run actually did. Ask it to check and it will.The setting still applies as written on ticket-triggered and scheduled agents, which have hours to work in and nobody waiting on them.A chat agent can only read runs of the workflows it is allowed to trigger — the list you set above. If it needs to report on another workflow, add that workflow to the list.

​
Scheduled Execution

When an action needs to happen in the future, the agent schedules the workflow to run at a specific date and time. This creates a Scheduled Work entry that you can view and manage from your dashboard.
When scheduling for the future, the agent can schedule any workflow in the allowlist or the current workflow itself. Self-scheduling is useful when the agent needs to re-process the same ticket later (e.g., check back in a week to verify a fix).

​
What Gets Scheduled

When the agent schedules work for the future, it creates an entry with: All scheduled work appears in the Scheduled Work section of your dashboard where you can view, reschedule, or cancel pending entries.

Scheduled Work Dashboard

Learn more about managing scheduled work from the dashboard

​
Example Scenarios

​
Offboarding with Delayed Actions

An agent processing a termination ticket on March 1st for an employee whose last day is March 15th:

​
Follow-Up Verification

After resolving a recurring issue:

​
Conditional Workflow Chaining

An agent determines the ticket needs specialized handling:

​
Requirements

The tool can only trigger or schedule workflows that are:
  • Enabled — Disabled workflows cannot be triggered or scheduled
  • Triggered type — Only event-triggered workflows support this

​
When a workflow your instructions name is not available

If your instructions tell the agent to run a workflow first when it is available, and that workflow is not in its allowlist, the agent skips that step and carries on with the rest of the job. It notes the skipped step in its run summary, unless your instructions set an exact format for that summary. To make the agent stop instead, say so in the instructions, for example: “If the Bundling workflow is not available, do not assign the ticket; add a note for the dispatcher.”
When scheduling, the time must be in the future. The agent cannot schedule work for a time that has already passed.

​
Which target settings apply to a direct invocation

A direct hand-off from one agent to another is not the same as a PSA event reaching the target. When an agent triggers a target with this tool, most of the target’s own trigger settings are deliberately skipped, so the source agent is in control of the hand-off. This is different from how the target behaves when a PSA event arrives on its own. There are three separate gates, and they are easy to confuse: For a direct invocation, the target’s settings apply as follows:
Because the target’s Filter Ticket conditions and its configured trigger event are skipped, those settings are a gate on PSA events, not a guard against a direct invocation from another agent. If you only want a target to run for certain tickets, control that on the source agent — through its instructions and its own filter — because the source agent decides which tickets to hand off. Set the allowlist on this tool to the exact targets you are comfortable being invoked directly.

​
Instructions the source agent passes on

When the source agent triggers a target immediately and that call starts a new run, the instructions it writes reach the target as handoff notes: what the source agent found, and what it asks the target to do. If the target is already running for that ticket, no new run starts and the notes do not reach it. The target is told to rank these notes below its own custom instructions. This lowers their weight, but it does not guarantee the target ignores a note that conflicts with its instructions. The guard you can rely on is the source agent: its ticket filter and its instructions decide which tickets it hands off and what it asks for. Still write a rule the target must keep on every run into the target’s own custom instructions. For example, on a dispatch agent: “Only assign tickets in the Ready for Dispatch status. If the ticket is in any other status, stop.” Instructions you give yourself through Run Now keep their full weight for that run.

Scheduled Work

View and manage all scheduled work from the dashboard

PSA API

Add internal notes to document trigger or scheduling decisions in the ticket