Skip to main content

What is a Job Template?

A Job Template is a reusable definition for running an Ansible playbook against an inventory with specific credentials and settings. Job templates are the primary way to launch automation jobs in AWX, providing a consistent interface for executing playbooks with parameterization and access control.
Job templates act as a “play button” for your automation - they define what to run, where to run it, and how to run it.

Core Concepts

Required Components

From the JobTemplate model (awx/main/models/jobs.py:194-558): A job template requires:
  1. Project: The source of playbooks
  2. Playbook: Specific playbook file from the project
  3. Inventory (or prompt on launch): Target hosts
  4. Credentials: Authentication for target systems

Key Fields

Prompting on Launch

Job templates can be configured to prompt for values at launch time using ask_*_on_launch fields:
Prompted credentials and variables override the template’s defaults. Ensure users understand the security implications of prompted launches.

Credentials

Job templates support multiple credential types simultaneously:
You can attach:
  • One SSH credential (machine credential)
  • Multiple network credentials
  • Multiple cloud credentials
  • Multiple vault credentials

Extra Variables

Extra variables follow a specific precedence order:
  1. Job launch extra vars (highest)
  2. Survey answers
  3. Job template extra vars
  4. Inventory variables
  5. Host/group variables (lowest)
Variables are merged at runtime:

Surveys

Job templates can have surveys that prompt users for input:
Survey answers are passed as extra variables. Password-type questions are encrypted.

Job Slicing

Job slicing enables parallel execution across multiple job instances:
When job_slice_count > 1, AWX:
  1. Creates a workflow job instead of a regular job
  2. Creates one job node per slice
  3. Distributes inventory hosts across slices
  4. Runs slices in parallel
Job slicing is effective for large inventories with independent hosts. It won’t speed up playbooks with dependencies between hosts.

Jobs

When a job template is launched, it creates a Job (awx/main/models/jobs.py:560-868):

Job Lifecycle

1

Pending

Job is created and queued
2

Waiting

Job is waiting for dependencies (project updates, inventory updates)
3

Running

Job is executing on an AWX instance
4

Completed

Job finished with status: successful, failed, error, or canceled

Job Fields

Jobs inherit all fields from the job template plus:

Dependencies

Jobs may wait for dependencies before running:
Dependencies include:
  • Project updates (if scm_update_on_launch)
  • Inventory updates (if inventory sources have update_on_launch)

Execution Environments

Job templates can specify an execution environment:
If not specified, the execution environment is resolved from:
  1. Job template’s execution_environment
  2. Project’s default_environment
  3. Organization’s default_environment
  4. Global default execution environment

Instance Groups

Job templates can specify which instance groups run the job:
Instance groups control where jobs execute in clustered/containerized environments.

API Endpoints

List Job Templates

Create Job Template

Launch Job

Cancel Job

Relaunch Job

Permissions

Job templates have these roles (jobs.py:264-275):
  • Admin Role: Full control over the template
  • Execute Role: Can launch jobs
  • Read Role: Can view template details
The execute role is inherited from the organization’s execute_role, making it easy to give users permission to run automation across all templates in an organization.

Notifications

Job templates can trigger notifications on job events:
Notifications can be sent:
  • When job starts (started)
  • When job succeeds (success)
  • When job fails (error)

Best Practices

Instead of prompting for raw extra_vars, create surveys with typed inputs (integers, choices, etc.) for better UX and validation.
Set use_fact_cache: true to cache Ansible facts. This speeds up subsequent runs and enables fact-based smart inventories.
Always set a timeout to prevent runaway jobs. Consider the longest expected runtime plus buffer.
Use the limit field or prompt for it to run playbooks against subsets of inventory without creating duplicate templates.
For large inventories with independent hosts, use job slicing to parallelize execution and reduce total runtime.
Only enable allow_simultaneous if your playbooks are idempotent and safe to run concurrently.