# Job templates and jobs

> Source: https://docs.clonepartner.com/ui/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:

```yaml
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:

```yaml
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](/reference/job-templates). Dashboard YAML is in [Dashboards](/reference/dashboards).