Guide 09 · Developer docs

Automation, jobs and integration

A job is a trigger, conditions and an ordered list of actions, set up under Customization › Orchestration in the admin; jobs were called hooks before the module was renamed, and the API's routes keep that name. What starts a job, what it can do, branches and loops, email, scheduled work, integrations with other systems, and every event and action.

L2–L3

Unit 01 of 08 4 pages

The job model

Updated 23/10/2026 01:48

What a job is made of, how to read the log of a run, how jobs move between environments, and how to test one without touching live data. For anyone building jobs, before the first one goes live.

Start with Anatomy of a job: the parts every job has, the settings that matter from the first day, the variables its templates receive, and the naming that keeps fifty jobs maintainable. Reading a job run comes next and before anything else you build, because every later page debugs through the run log.

The last two pages are for when a job is ready to leave your hands. Moving jobs between environments lists what an export carries and what must be set again after an import; Testing a job without touching live data gives the procedure, the admin's run buttons and the staged first run for jobs that cannot be tested safely.

In this unit

Read in order

01 Anatomy of a job A job is a set of triggers, an ordered list of actions and a few settings. One complete job read top to bottom, the settings that matter from the first day, the variables every job template receives, and how to name jobs so a site can be handed over. 02 Reading a job run Every run of a job leaves a record in Batch Logs: a status for the run and for each action, with the action's output. How to read one in the right order, what each status means, what a re-run does, and how long runs are kept. 03 Moving jobs between environments Jobs move from staging to production with the admin's export and import, not by hand. What travels with a job, what does not (its site, schedule, published state and the site data its credentials live in), and the checks to make after every import. 04 Testing a job without touching live data Jobs have no dry-run mode: every action does what it says. How to test one anyway, with a test record, a narrowed trigger, a guard and the admin's run buttons, what cannot be tested safely, and how to limit the damage when a job must first run for real.