Who this is for. Whoever promotes jobs from a development or staging site to production. Afterwards you can move a set of jobs in one file and know exactly what to set again on the other side.
Moving jobs is a weekly task on most builds, and rebuilding them by hand is how two environments drift apart: an identifier typed differently, a branch missed, a retry count left at zero. Export them instead.
Exporting and importing
- On the source site, open System › Utilities › Export, choose the jobs, and download the file. Layouts and input types are exported with the same tool. Only administrators see it.
- On the target site, System › Utilities › Import, upload the file.
- Choose the mode. By default a record the target already has, recognised from an earlier export or import, is skipped as it is. Tick Update existing records to overwrite it with the version in the file.
The file carries a checksum, and an edited file is refused. Change the job on the source and export again rather than editing the file.
What travels and what does not
| Travels with the job | Does not travel |
|---|---|
| Name, description, category, Synchronous execution, Batch persistence | Published: the imported job is inert until someone publishes it |
| Every action with its full configuration, its identifier, its position and whether it is published, including URLs and headers typed into it | Run on site and the schedule (scheduled and recurring executions): set both again |
| Entity event triggers: entity, method, Pre-Event properties, and any record or parent record id they are narrowed to | Site data, where a job's keys and endpoint addresses belong |
| Web event triggers: slug, methods and Authentication required | Job runs |
| Links between actions (a loop's or a file's source action) and the target of a Trigger job action, re-linked to the imported records | The template files under templates/hooks/: they deploy with the theme repository, so the right branch must be live on the target |
The imported job is a new record on the target, created by the person who imports it, and its actions run with that person's permissions.
Checks after every import
- Record ids. A trigger narrowed to form 12 is narrowed to whatever has id 12 on the target, which is usually a different form, or nothing. The same goes for record ids typed into actions. Set each one again.
- Addresses. An HTTP request typed with a partner's sandbox URL still points at the sandbox. Keep addresses in site data, as the worked integration does, and the problem disappears.
- Credentials. Site data did not travel: set the target's own keys. A key typed into a header did travel, which is why keys belong in site data (Credentials for a third party).
- Web event slugs. The imported endpoint answers at the same slug on the target's hostname. A slug that was shared with a partner for testing now opens production; change it if that matters.
- Site and schedule. Set Run on site again, then the schedule, which needs a site.
- Templates. Every file the actions name exists on the branch deployed to the target.
- Publish, then trigger it once on purpose and read the run (Reading a job run).
The same procedure as a checklist to follow: Move jobs from staging to production safely.