Job Templates

Job templates let admins maintain reusable job blueprints and create linked jobs from them.

Use a template when several jobs should share the same workflow, but still need different values such as service names, image tags, paths, compose files, or target-specific labels.

For example, a Docker service update workflow reused for Ordyn api, frontend, edge, cache, net, SNMP, and Telematik services

In the frontend, templates live under Operations > Job Templates.

Creating templates

Templates are authored in a full-page editor that follows the normal job editor workflow.

Use New template in Operations > Job Templates to start from an empty template. You can also open an existing job and choose Create template from job from the job actions menu.

Creating a template from a job copies the job into the template editor. The original job is not changed. The template editor then lets you adjust the copied workflow, define template inputs, and save the result as a reusable template.

Select the template execution scope:

• Endpoint creates linked endpoint jobs.
• Infrastructure creates linked infrastructure jobs and requires a Runner pool.

Infrastructure templates use the infrastructure task catalog and start with Run inline script when no compatible task exists.

The template editor includes a dedicated Template inputs step. Use it to define the values that must be filled when creating or editing a linked job. Job fields that support templating can reference those values with:

{{ template.parameter_name }}

Creating linked jobs

A template is not run directly. Instead, create one or more linked jobs from the template.

A linked job behaves like a normal job in its execution scope:

• endpoint linked jobs can use assignments, endpoint automations, composition tasks, and self-service
• infrastructure linked jobs use the template's Runner pool and can use schedules, completion automations, and webhook automations
• both scopes have job runs, task results, history, and audit information

The linked job stays connected to its template. When the job runs, Ordyn uses the template workflow together with the linked job's template input values.

What the template controls

The template owns the shared execution behavior of linked jobs:

• tasks and task order
• execution scope
• Runner pool for infrastructure templates
• timeout and validity windows
• endpoint requirements, execution type, shutdown policy, concurrency, desktop execution, and user interaction for endpoint templates

Change these values on the template when the shared workflow should change for every linked job that uses it.

What the linked job controls

Each linked job owns the values that make that job useful in a specific place:

• job name, friendly name, and description
• job folder
• schedules and event automations
• endpoint assignments, composition usage, and self-service presentation for endpoint linked jobs
• template input values

When editing a linked job, the editor shows only the fields that belong to the linked job. The shared execution workflow is edited on the template.

Template inputs

Templates define named inputs. Supported input value types are:

• string
• select
• number
• boolean
• json

Use json for structured values such as arrays or objects, for example a list of Docker images.

Use select for a fixed, ordered list of label/value options. Labels and values must be non-empty and unique. The linked-job editor shows the labels and stores the selected underlying value as a string. A default must match one of the configured option values; no option is selected automatically when no default exists.

Inputs can also have operator-facing labels, descriptions, defaults, and required flags.

When typing in a templated field, entering {{ opens autocomplete. The suggestions include template inputs, persistent variables from the variable catalog, and common runtime references such as endpoint fields, job run fields, loop values, and previous step results.

Use template inputs for values that should differ between linked jobs. Examples include:

• service name
• Docker image list
• Docker tag variable key
• base path
• compose file name
• signature public key path

Runtime variables inside template inputs

Template inputs can contain normal Ordyn runtime templates.

For example, a linked job input value can be:

{{ vars.ordyn_frontend_base_path }}

This lets a template combine two layers:

• template.* selects the reusable job-specific values
• vars.*, endpoint.*, job.vars.*, steps[...], and other runtime references still resolve when the job runs

For example, a template can define a task path like:

{{ template.base_path }}/{{ template.compose_file }}

One linked job can then set:

base_path = {{ vars.ordyn_frontend_base_path }}
compose_file = {{ vars.ordyn_frontend_compose_file }}

When an endpoint job runs, Ordyn keeps endpoint runtime references meaningful for the target endpoint. Infrastructure templates can use job, Runner, trigger, loop, and previous-step values without endpoint context.

Editing templates and linked jobs

Edit the template when you want to change the shared workflow.

Edit a linked job when you want to change that job's name, description, folder, schedules, automations, scope-specific usage settings, or template input values.

The template detail page shows jobs that were created from the template. A linked job's overview links back to its template.

Copying linked jobs

Copying a linked job creates a standalone job copy.

The copied job is independent from the template. Use this when you want to branch from a template-based job and then manage the copy independently.

Create another linked job from the template when you want that job to continue using the template.

Example

A template for Ordyn service container updates might define inputs like:

{
  "service_name": {
    "type": "string",
    "label": "Service name",
    "required": true
  },
  "base_path": {
    "type": "string",
    "label": "Base path",
    "required": true
  },
  "compose_file": {
    "type": "string",
    "label": "Compose file",
    "default": "compose.yml",
    "required": true
  },
  "images": {
    "type": "json",
    "label": "Images",
    "required": true
  },
  "tag": {
    "type": "string",
    "label": "Docker tag",
    "required": true
  }
}

The template can then use those values in job fields and task payloads:

Update {{ template.service_name }}
{{ template.base_path }}/{{ template.compose_file }}
{{ template.images }}
{{ template.tag }}

When creating a linked job, the template input values may still point to runtime variables:

{
  "service_name": "Ordyn Frontend",
  "base_path": "{{ vars.ordyn_frontend_base_path }}",
  "compose_file": "{{ vars.ordyn_frontend_compose_file }}",
  "images": [
    "docker.hank-it.com/ordyn/frontend"
  ],
  "tag": "{{ vars.ordyn_frontend_tag }}"
}

When to use templates

Use job templates when:

• several jobs should share the same execution workflow
• each linked job needs a small set of different values
• workflow changes should be maintained in one template
• the resulting jobs still need the scheduling, automation, run history, and audit behavior available to their execution scope

Use a normal job without a template when the workflow is unique or unlikely to be reused.

Use composition tasks in a parent job when the problem is rollout order, batching, or staged execution across endpoint sets rather than sharing one task tree.