Job templates and jobs

A job template is a reusable graph. A job is a configured instance of that graph.

Build a job template

Open Job Templates to create or import template YAML. A template defines:

• template-level connector slots;
• task nodes;
• connector_mapping from task slots to template slots;
• depends_on edges;
• optional create-time arguments;
• optional editable job_config;
• a failure policy.

Example shape:

name: ticket-migration
 
connectors:
  source:
    type: csv
  destination:
    type: sqlite
 
tasks:
  validate:
    task: validate-tickets
    connector_mapping:
      source: source
 
  migrate:
    task: migrate-tickets
    depends_on: [validate]
    connector_mapping:
      source: source
      destination: destination
 
on_failure: pause

The task names must match registered tasks, every required slot must be mapped, and the dependency graph must be acyclic.

Arguments versus job configuration

Use template arguments for values chosen once when a job is created:

arguments:
  ACCOUNT_ID:
    type: string
    required: true
 
tasks:
  migrate:
    task: migrate-account
    arguments:
      account_id: ${ACCOUNT_ID}

Use job_config for values operators should edit later, such as field mappings or sync toggles. Each run snapshots the current values.

Do not write arguments.account_id as a task-node value. Task-node argument values are literal unless they use a declared ${NAME} template placeholder.

Create a job

From a template detail page:

1. select Create Job;
2. name the job;
3. bind a stored connector to each template slot;
4. complete template arguments;
5. confirm creation.

Connector type mismatches are rejected.

Job detail

The job page brings together:

• current job configuration;
• the task DAG and node statuses;
• run-all and selected-task controls;
• per-node task customization;
• attached dashboards;
• job-run history.

Select individual nodes when you need a partial run. Dependencies are included by default. Skipping dependencies should be reserved for a node that can safely run against already-prepared state.

Customize one job

An admin can edit a task node for one job without changing the shared task library. The override is keyed by DAG node, so two nodes using the same base task can diverge.

Customized nodes show a badge. Reset to original removes the override for future runs.

The run's provenance still points to the pinned library task and version even though the override YAML is what executed. Document the customization when audit readers need to distinguish them.

Failure and resume

The template failure policy controls downstream behavior:

• pause stops the graph in a resumable state;
• abort fails the job run;
• continue allows unaffected work to continue.

Validation task results can stop work even when their process exits normally. Review both job-run status and child task messages.

Resume a paused or failed job run only after correcting the external condition or configuration that caused it.

Archive and delete

Archive a job to stop normal use while preserving history and dashboards. Delete only when the job and its dependent records are no longer required.

The complete template schema is in Job templates. Dashboard YAML is in Dashboards.