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 Event History. 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.

​
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 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.

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