Schedules and triggers

Start work on a timetable or an event, and distinguish new work from resuming a waiting run.

Start an agent or workflow manually until its input and result behave as expected. Then choose an entry point based on what should cause the work to happen.

Choose the right entry point

You want to…	Use
Start work from a person or your application	The run launcher or SDK start operation.
Run at a future time or on a repeating timetable	A schedule.
Start work when another system reports something	An event trigger with a start binding.
Deliver a signal to an existing waiting workflow	A trigger with an answer-wait binding and matching correlation key.
Limit how many starts proceed together	A queue, optionally combined with debounce.

A workflow Timer delays a step inside an existing run. A schedule creates a new run when it fires. A signal answers a particular wait; it does not start that workflow again.

Create a schedule

Open the agent or workflow's Triggers section, or the environment's schedules area, and choose New schedule. Publish the target first.

Give the schedule a recognizable name and select What to run.
Choose Repeat: once, interval, daily, weekdays, weekly, monthly, or custom cron.
Set the time and, for calendar schedules, the time zone. An interval must be at least one minute. Custom cron has five parts: minute, hour, day of month, month, and day of week.
Review the next execution times. Monthly dates 29–31 skip months that do not contain that date.
Choose If one is missed: run the latest missed occurrence if within a day, or skip it. Intervals default to skipping.
Supply Input as JSON matching the published target's schema, then save.

The schedule runs the selected published version even after a new version is published. Review and update the target intentionally when rolling out a change. The schedule also depends on current access; revoked permissions can stop it from starting work.

Create an event trigger

Choose Create trigger and give it a name. Under When an event arrives, choose whether to start new work or answer a wait. Select the published target and define the Event payload schema. Events that do not match are recorded and refused.

For an answer-wait binding, supply the Wait node in the workflow. The incoming event's correlation key must match that wait's task reference. This is how an external result reaches the correct waiting execution.

Enable Time-sensitive when stale events should not cause work. Configure Too old after (seconds) and ensure producers provide the event time. Set the maximum event-chain hops to bound chains where one run sends another event.

Your integration sends events through the supported API. The developer workflow guide and API reference cover the payloads; creating a trigger by itself does not connect an external system.

Debounce repeated starts

Debounce combines starts with the same key until they stop arriving for the configured period. Use it for a document that receives several edits in quick succession. Choose a key identifying the document so unrelated documents do not collapse together.

A queue limits concurrent runs after work is submitted. Debounce controls when a start is submitted. They can be used together.

Follow up and monitor

Schedule follow-up on a completed run creates new linked runs with its prior context. The completed run remains unchanged. Use this for a future check-in, not for answering a currently pending question or approval.

Inspect the trigger's event records when nothing starts: waiting, started, answered, too old, and refused describe different outcomes. Also inspect the target's Access checks and queue. Before retiring a version, move schedules and triggers that still reference it. See Publishing and versions.