Override a task for one job

A job can store replacement task YAML for one DAG node. Future runs of that job use the replacement without changing the shared task library, template, or another job.

Use an override for an exceptional job-specific change that cannot be expressed through task arguments or job_config. Put reusable behavior back into the shared task.

Edit from Job Details

1. Open the job.
2. Find the task row and choose its edit action.
3. Edit the complete task YAML.
4. Validate and save.
5. Confirm the task row shows Customized.

The override is keyed by the job task key, not only the shared task name. Two DAG nodes that reference the same library task can have different overrides.

Connector requirements

The replacement YAML must declare every connector slot used by that node's connector_mapping:

name: migrate-tickets-custom
output: none
 
connectors:
  source:
    type: truto
  destination:
    type: postgres
 
steps:
  - name: list
    type: call_method
    config: |
      {
        "connector": "source",
        "method": "list",
        "args": {
          "resource": "tickets",
          "unified_model": "ticketing",
          "integrated_account_id": arguments.account_id
        }
      }

Envoy still applies the DAG node's connector mapping and arguments at run time. Do not inline stored connector IDs, endpoints, or credentials.

Validation and API

Admins can manage overrides through:

• GET /api/jobs/{id}/tasks/{taskKey}/yaml;
• PUT /api/jobs/{id}/tasks/{taskKey}/override with { "yaml_content": "..." };
• DELETE /api/jobs/{id}/tasks/{taskKey}/override.

The save endpoint runs the normal task parser and validator and checks connector slots against the DAG node.

Run and provenance behavior

At run time and on resume, Envoy uses the override as the base task YAML, then applies the node's mapped connectors and arguments.

The task run still records the pinned shared task ID and version as provenance. The executed YAML can therefore differ from the pinned library version. Check the job's Customized state when investigating history.

An override changes future execution for that job. It does not mutate completed runs or the global task's version history.

Test an override

1. Compare the shared YAML and proposed replacement.
2. Keep the change as small and documented as practical.
3. Validate and save the replacement.
4. Run the customized node against a bounded dataset.
5. Inspect resolved arguments, connector mapping, logs, and metrics.
6. Rerun the same input to verify idempotency.
7. Run the affected dependency path before scheduling.

Avoid increasing concurrency until provider limits and destination idempotency are verified.

Reset to the shared task

From the editor's overflow menu, choose Reset to original. This deletes the replacement; future runs use the pinned task version again.

Before resetting, compare behavior and confirm the shared task supports the job's current data and configuration. Resetting does not roll back writes made by the customized version.

See Job templates, Task structure, and Configure a job between runs.