Analysis triggers
An analysis trigger is a schedule attached to an existing analysis that queues a fresh run automatically when it fires. Instead of returning to the platform to press "Run" every week, you configure the cadence once and Diafunc re-runs the analysis on your behalf, reusing the same data table, targets, questions, segment key, and depth preset as the original run.
This is the fastest way to keep a report current: point a trigger at an analysis whose underlying data source refreshes on a schedule, and each run picks up the latest data and rebuilds the report with it.
This is the fastest way to keep a report current: point a trigger at an analysis whose underlying data source refreshes on a schedule, and each run picks up the latest data and rebuilds the report with it.
Not the same as function triggers
Diafunc has two unrelated features that both use the word "trigger". They are easy to confuse, so it is worth being explicit:
A function trigger runs a single function evaluation; an analysis trigger runs an end-to-end analysis (data preparation, symbolic-regression modelling, and report generation). If you were looking for the event-driven function triggers configured in the Lab (and the
Functions
| Feature | What it does | Where |
|---|---|---|
| Analysis trigger | Re-runs a whole analysis on a schedule, producing a fresh report each time. | This page. |
| Function trigger | Invokes an Intelligent Function on a time- or event-driven basis (for example when a table changes). | Documented under Functions. |
A function trigger runs a single function evaluation; an analysis trigger runs an end-to-end analysis (data preparation, symbolic-regression modelling, and report generation). If you were looking for the event-driven function triggers configured in the Lab (and the
trigger command group in the CLI), see the Functions documentation instead. Schedule kinds
Every trigger has a kind that decides how often it fires and a schedule spec that gives the exact time or cadence.
A Quartz cron expression has six fields:
| Kind | Fires | Schedule spec | Example |
|---|---|---|---|
One-off (ONCE) | A single run at one moment in time, then deactivates itself. | An ISO-8601 instant (UTC). | 2026-07-01T06:00:00Z |
Recurring (CRON) | A run on every occurrence of the cron expression, indefinitely, until you pause or delete it. | A Quartz cron expression. | 0 0 6 * * ? |
A Quartz cron expression has six fields:
second minute hour day-of-month month day-of-week. For example 0 0 6 * * ? means "at 06:00:00 every day", and 0 30 7 ? * MON means "at 07:30 every Monday". Cron times are interpreted in UTC. Creating a trigger in the platform
Open the Analysis panel for a project from the Lab left menu and find the Triggers section below the run history. Press Add trigger to open the editor and pick a cadence: every day (a time of day), every week (a weekday and a time), every month (a day of the month and a time), once, at a set time (a single moment), or advanced, which takes a raw Quartz cron expression for cadences the presets do not cover.
The recurring presets build the cron expression for you, so you only need Quartz syntax for the advanced option. Every time field is in UTC, which is the zone the platform evaluates schedules in. As you fill the editor in, it shows the exact moment the schedule would first run, resolved by the platform rather than guessed in the browser; an expression that cannot be parsed, or one whose last occurrence has already passed, says so there, and Create stays disabled until the schedule has a real next run.
Once saved, the schedule appears in the table described in plain words, such as "Every Monday at 07:15 UTC", with its raw spec underneath, its next run (also in UTC, like every other time on this surface), and its status. Each row can be paused (temporarily stop firing without losing the schedule), resumed, or removed. A paused trigger keeps its configuration but never fires until you resume it.
The recurring presets build the cron expression for you, so you only need Quartz syntax for the advanced option. Every time field is in UTC, which is the zone the platform evaluates schedules in. As you fill the editor in, it shows the exact moment the schedule would first run, resolved by the platform rather than guessed in the browser; an expression that cannot be parsed, or one whose last occurrence has already passed, says so there, and Create stays disabled until the schedule has a real next run.
Once saved, the schedule appears in the table described in plain words, such as "Every Monday at 07:15 UTC", with its raw spec underneath, its next run (also in UTC, like every other time on this surface), and its status. Each row can be paused (temporarily stop firing without losing the schedule), resumed, or removed. A paused trigger keeps its configuration but never fires until you resume it.
Refreshing the data before a run
An analysis whose data comes from a data source (see A data source that feeds an analysis ) can be scheduled so that every run sees current data. The trigger editor then offers one more switch: Refresh the data first. With it on, a firing does three things in order:
After a firing that went through, the row says "The data was refreshed and the run was queued." A recurring trigger tries again at its next time whatever happened. A one-off trigger that refreshes first stays in the table afterwards, inactive, so that its outcome can be read. The switch can be turned on and off for an existing trigger with the refresh button in its row.
Without the switch, a trigger runs the analysis on the data as it is. A data source with a schedule of its own still refreshes the data at its own times, independently of any run.
- It fetches every data source that feeds the analysis.
- It builds the analysis's data once, from all the fresh files together.
- It queues the run.
| What happened | What the trigger does |
|---|---|
| A data source could not be fetched, or brought no data | No run. The data stays as it was. Files already fetched in this firing are not used: the data is built from all of them or from none. |
| A fetched file no longer fits the way the data was built | No run. The data stays as it was, and the sentence names the file and the reason. |
| A run of the analysis or an import of its data was already under way | The refresh is skipped and no second run is started. |
| A data source was deleted meanwhile | Its file stays as it is. The other data sources are refreshed and the run is queued. |
| No data source feeds the analysis | The run is queued on the data as it is. |
After a firing that went through, the row says "The data was refreshed and the run was queued." A recurring trigger tries again at its next time whatever happened. A one-off trigger that refreshes first stays in the table afterwards, inactive, so that its outcome can be read. The switch can be turned on and off for an existing trigger with the refresh button in its row.
Without the switch, a trigger runs the analysis on the data as it is. A data source with a schedule of its own still refreshes the data at its own times, independently of any run.
Creating a trigger from an agent (MCP)
The same schedules can be managed programmatically through the Diafunc MCP tools, which is convenient when an assistant or automation manages the analysis. Four tools cover the lifecycle:
Schedule a single run at a fixed time:
Schedule a recurring run (here, every day at 06:00 UTC):
Schedule a weekly run that fetches the analysis's data sources first:
Pause a trigger without deleting it by updating its
create_analysis_trigger, list_analysis_triggers, update_analysis_trigger, and delete_analysis_trigger. Schedule a single run at a fixed time:
create_analysis_trigger · one-off
Schedule a recurring run (here, every day at 06:00 UTC):
create_analysis_trigger · recurring
Schedule a weekly run that fetches the analysis's data sources first:
create_analysis_trigger · refresh the data first
Pause a trigger without deleting it by updating its
active flag (pass a new scheduleSpec of the trigger's existing kind instead to reschedule it): update_analysis_trigger · pause
What happens when a trigger fires
When a trigger's next fire time arrives, Diafunc queues a brand-new analysis run that reuses the parent analysis's settings: the same raw data table, analysis function, targets, questions, and depth preset. The run joins the normal queue and, when it starts, produces a fresh report exactly as if you had pressed "Run" by hand. It appears in the same run history as your manual runs.
A trigger re-runs against whatever data the analysis currently holds, so a data source that feeds the analysis keeps the report up to date. The dependable way is one trigger with Refresh the data first, which fetches and then runs, in that order; a data source with its own schedule and a trigger with its own are two clocks that are not coordinated. Runs a trigger queues notify like any other run: with the analysis's Email me when a run finishes toggle on (on the same Analysis panel), each scheduled completion or failure lands in your inbox.
After firing, a one-off trigger has done its single job and is gone, unless it refreshes the data first, in which case it stays, inactive, with its outcome. A recurring trigger computes its next fire time from the cron expression and waits for the next occurrence. Each fired run consumes credits at the analysis's depth preset, just like a manual run, so keep the cadence and depth in mind for recurring schedules.
A trigger re-runs against whatever data the analysis currently holds, so a data source that feeds the analysis keeps the report up to date. The dependable way is one trigger with Refresh the data first, which fetches and then runs, in that order; a data source with its own schedule and a trigger with its own are two clocks that are not coordinated. Runs a trigger queues notify like any other run: with the analysis's Email me when a run finishes toggle on (on the same Analysis panel), each scheduled completion or failure lands in your inbox.
After firing, a one-off trigger has done its single job and is gone, unless it refreshes the data first, in which case it stays, inactive, with its outcome. A recurring trigger computes its next fire time from the cron expression and waits for the next occurrence. Each fired run consumes credits at the analysis's depth preset, just like a manual run, so keep the cadence and depth in mind for recurring schedules.