Scheduler & Unattended Runs | ATX AnalyticsTable Handbook

Scheduler, parameters & unattended operationSequence numbers, timezone-correct triggers, and formulas that always follow data. The scheduler runs background work without blocking the application: refresh every pinned binding or a single one, re-run a saved query, re-import a file from disk or a bucket, write an export, or zip a project backup with rolling retention. Parameters are the glue that makes it unattended — a named dynamic value defined once and referenced anywhere, resolved at run time so a nightly job picks up the right date, file and folder without anyone editing anything.

What it does

Schedulable targets: all grid bindings, one binding, a pinned query, a file import, an export, a project backup
Triggers: every N minutes, at a specific time on chosen weekdays in a chosen timezone, manual, at startup, and catch-up for slots missed while closed
Explicit DST handling — a nonexistent time shifts to the first valid moment, an ambiguous one fires once
Sequence numbers: numbered schedules run one at a time in ascending order; unnumbered ones run in parallel
Formulas recalculate within the same run after every data refresh, before the next sequence step starts
Backups zip the whole project folder to a local, network or cloud destination with rolling retention
Ask Greg can propose a schedule for a pipeline, an alert, a refresh or a PDF export, showing its next three runs before you place it — never more often than every 15 minutes

How it works

A parameter has a name, an expression — a literal, or a formula such as =TODAY()-1 — and a format such as YYYYMMDD.
Referenced as ${name}, it resolves inside file paths, SQL, visual query filters, and export folder and file names.
Only defined names are substituted, so a typo stays visible instead of silently becoming blank.
A typical morning chain: 06:00 sequence 1 refreshes the orders query, sequence 2 the FX rates, sequence 3 exports the report, sequence 4 backs up the project.
Safety rails: a schedule still running when its next slot arrives is skipped for that slot, and runs past the configured timeout are marked as timeouts.
Restore unpacks a chosen backup into a new empty folder — it never overwrites an existing project.

Practices that keep it reliable

Give every schedule in a dependent chain a sequence number; parallel is only safe when nothing downstream reads the result
Set the timezone explicitly rather than relying on the machine's — a report that moves with the clocks is a report nobody trusts
Keep at least seven rolling backups and test a restore once, into a scratch folder, before you need one

In a regulated environment

Every export schedule's full definition — source, multi-sheet composition, destination, delimiter, encoding, line endings, cadence — is mirrored as JSON into the project's Export folder and re-synced on every change.
Those mirrors contain configuration only and never data, so committing the folder gives a reviewable diff of every parameter change without any disclosure risk.
Backups checkpoint the database first, so the snapshot is internally consistent rather than merely recent.

Screens

The scheduler — targets, triggers, sequence numbers and per-schedule timeouts.
Refresh scheduling — all bindings in one run, or one binding on its own cadence.
Parameters — named values with expressions and formats, resolved at run time.
Backups — the whole project folder, zipped to disk or cloud, with rolling retention.

Related guides

Automated Excel & scheduled reports
Reports & PDF automation
Scheduled reports: definition

ATX Institute on LinkedIn

This site needs JavaScript for the full experience. Every page above is reachable without it.