Scheduled workflows

Most automation in Antly reacts to something: a record is created, a ticket changes stage, an approval is signed. Scheduled workflows are the exception. They are not attached to an object, a record or a ticket — they simply run on a timetable you choose, in the same way a cron entry would on a Linux box, only configured from friendly options rather than * * * * *.

Reach for one when the work is driven by the clock rather than by a record: a nightly overdue-invoice sweep, a Monday-morning digest, a monthly reconciliation, a quarterly licence check.

Where to open it

Path	Role
Main menu → Automation → Scheduled Workflows	The list of every cronjob in the workspace, with its recurrence, next run and last run
Scheduled Workflows → (name)	The detail page: Overview, Runs and Versions tabs, plus the manual-run action
Scheduled Workflows → (name) → Versions → Open Studio	The Workflow Studio canvas where you build what the cronjob actually does

How it differs from a periodic trigger

Both run on a recurrence, and both use exactly the same frequency picker. The difference is what they run against.

	Periodic object trigger	Scheduled workflow
Bound to	An object namespace	Nothing
Fires	Once per matching record, every slot	Once per slot
instance in merge templates	The matching record	The run itself
Set up in	Object settings → Workflow Automation	Automation → Scheduled Workflows

If you want "every overdue invoice, every night", use a periodic object trigger — it hands you each invoice. If you want "once a night, go and work out what is overdue", use a scheduled workflow and fetch the data yourself with a Filter node.

Create a scheduled workflow

1. Open Automation → Scheduled Workflows and choose New Scheduled Workflow.
2. Give it a name that describes the business outcome ("Nightly overdue invoice sweep"), not the mechanism.
3. Pick the recurrence: frequency (daily, weekly, monthly, yearly), the interval, the days where relevant, and the time of day.
4. Save. Antly creates the workflow, its first version, and a periodic trigger node already carrying your schedule — so there is nothing to wire up before it can run.
5. Open the Versions tab → Open Studio and build what the cronjob does.
6. Publish the version. The scheduler skips unpublished workflows.

Times are interpreted in your workspace timezone, not UTC.

Changing the schedule

Use Edit schedule from the list row or the detail header. The recurrence lives on the workflow's trigger node, so editing it there and editing it in the studio are the same change — there is no second copy to keep in step.

The detail page

Tab	What it shows
Overview	Total and failed run counts, the recurrence in plain English, next run, last run, published version, and warnings if the workflow can never fire
Runs	Every firing of this cronjob, newest first
Versions	Template versions, publish state, studio access, download and restore

Two warnings on Overview are worth acting on immediately, because both mean the workflow will never fire:

• No recurrence set — the trigger has no schedule yet.
• No published version — the scheduler skips unpublished templates.

Running one manually

Run workflow now in the detail header (or Run now on the list row) fires the workflow immediately, outside its recurrence. This is the fastest way to prove a new cronjob works without waiting for the next slot.

A manual run is a first-class run: it appears in the Runs tab like any other, recorded against the user who started it rather than the scheduler.

Reading the run history

Each firing is recorded with:

Field	Meaning
Status	pending, running, completed or failed
Scheduled for	The slot the run belongs to — for a manual run, the moment you pressed the button
Started / Completed	Actual execution window
Duration	How long the graph took to run
Trigger	Scheduler, or Manual · <user>
Error	The failure message when a run did not complete

Using the run in your workflow

Because a scheduled workflow has no record behind it, the run itself is the pivot every node sees. That means instance in a merge template refers to the run:

In practice most scheduled workflows do not need this. The usual shape is: trigger → Filter node to fetch the records you care about → act on each one.

How the scheduler works

Useful when a run does not appear when you expected it:

1. Every minute, a scheduler pass looks at each published periodic trigger and writes the upcoming slot into the automation queue. If the due slot has just passed and was never buffered — because the tick was late, for example — it back-fills that slot too, so a 13:30 job can still fire at 13:33.
2. Every minute, a runner claims each due queue row and executes the workflow. Claiming happens before execution, so two workers can never fire the same slot twice.
3. A row that errors is retried up to three times before it is marked failed.

Slots from before the trigger existed are skipped — creating a daily 09:00 cronjob at noon will not back-fill this morning.

Operating guidance

• Publish a version before you expect the first run; an unpublished cronjob is silently inert.
• Use Run workflow now on a copy first if the workflow writes data — a cronjob that creates records will create them again on every manual run.
• Check the Runs tab after the first live slot rather than assuming success.
• Keep the work inside one run bounded. Fan-out from Loop and Filter nodes is capped by your plan tier (see Node reference).
• Name the cronjob after the outcome so the Runs list reads as an operational log.

For developers

• Workflow & automation namespaces — automation.ScheduledWorkflowRun, the workflow.TemplateGroup scheduling intents
• Scripts API
• JQL overview

Related

• Automation overview
• Triggers & events
• Node reference
• Workflow Studio
• Automation jobs & logs