Templates

Wrap an AWX job or workflow template in a Fabrik automation template — input schemas, variable mappings, categories, approval workflows, and check-mode defaults.

An Automation Template is a Fabrik wrapper around an AWX job or workflow template. It points at the AWX thing to launch, declares the input fields users will fill in, maps those fields to extra_vars, and owns configuration the AWX side can't express — validation rules, approver lists, category, tags, check-mode defaults.

Where AWX cares about how a playbook runs, the Automation Template cares about who can launch it, what they have to fill in, and what's allowed.

Template Library

The Templates page lists every automation template you can access. The toolbar has the usual picker tools:

Search by name, description, or tags.
Filter by category.
Filter by AWX connection.
Filter by type — Job Template vs Workflow Template.
Sort by recently updated, most-used, or alphabetical.

Clicking a template opens its detail view — the schema, variable mappings, approval config, and a New Request button that takes you to the request wizard.

Creating a template

Every Fabrik template wraps a template that already exists in AWX — you pick an AWX job or workflow template, then design the table schema and validations around it in Fabrik. There's no "from scratch" path; AWX is always the source.

Templates → New Template walks through one AWX template end-to-end:

Pick an AWX connection

Tabs for Job Templates vs Workflow Templates. Fabrik lists what's on the selected AWX, paginated 50 at a time. Search narrows the list.

Pick the AWX template

Clicking a template captures its ID and name. Workflow templates additionally capture the ordered workflow_job_nodes — each node becomes one schema sheet on the Configure page.

Configure immediately

The wizard hands off directly to the Configure page for the new template — you design the schema, variable mappings, and validations right after creation.

The Configure page

Every template ends up editable on the Configure Template page. Five areas sit on tabs.

Basics

Name, description, category, tags, is_public. The is_public toggle here follows the same rule as saved queries: admin-created templates are auto-public.

Schema

The heart of the template. One schema is one spreadsheet sheet — a table of columns that the user will fill in during the request wizard.

Job Templates have exactly one schema. awx_variable_name is the key under which rows go into extra_vars.
Workflow Templates have one schema per workflow node, in the node's execution order. Each schema's rows go to the matching workflow node.

Columns inside a schema:

Field	What it does
name	The internal key (must match your playbook's expected variable name).
display_name	The label shown to users in the form.
type	`text`, `number`, `select`, `multiselect`, `boolean`, `date`.
required	If true, empty cells fail validation before AWX ever runs.
help_text	Shown below the field in the wizard — use this to explain format.
validation_mode	`none`, `regex`, `static_list`, `query_list`. See Validations for the full story.
enum_values	For `select` / `multiselect`, the hard-coded allowed options.
min_rows / max_rows	How many rows the user must / may submit (schema level, not column level).

Column templates — reusable column definitions — let you drop a "Tenant Name" column with its regex and help text in one click. Covered in Validations.

Variable mappings

Fabrik ships every schema's rows to AWX under its awx_variable_name. The optional variable_mappings field lets you rename fields on the way out:

{
  "tenant_name": "tenant",
  "vrf_name": "vrf"
}

Column tenant_name in the table lands as tenant in extra_vars. Useful when the AWX-side variable names differ from the UI-friendly names you want in the form.

Leave it empty to pass column names through unchanged.

Execution

Three toggles:

Requires validation — if on, the request wizard enforces every column's validation before moving to the review step. If off, validation becomes advisory.
Allow validation bypass — lets users with the awx.bypass_validation permission submit despite validation errors. Off by default.
Enable check mode (dry-run) by default — if on, new requests default to Ansible --check. Users can override per-request unless Allow check mode override is off.

Check mode is worth understanding: with it on, the playbook reports what would change without changing anything. Good for staging verification; useless if the playbook's modules don't support check_mode: yes.

Approval

Off by default. Turn Requires approval on and the template sprouts:

Approver users — specific users who can approve requests against this template.
Approver groups — Django groups whose members can approve.
Auto-approve for owner — if the requester is also the template's creator, skip approval.

An approval-gated request goes pending → awaiting_approval → approved/rejected → running → .... Rejected requests carry a rejection reason and never launch AWX.

Approval is a template-level switch, not a per-request one — you can't opt a single high-stakes request into approval if the template doesn't require it.

Rollback (optional)

Each template can link to a rollback_template — a compensating template that undoes this one. Deleting Create Tenant templates can link to Delete Tenant, for example. Rollback is currently a pointer-only field; it surfaces a Rollback button on the execution detail that prefills a new request against the rollback template with the same input data.

This is the hook. What the rollback playbook actually does is on the playbook author — Fabrik doesn't verify the pair makes semantic sense.

Execution mode: bulk only

Templates once supported per_row and hybrid execution modes; both were removed. Every new template is created with execution_mode='bulk' and can't be set otherwise.

Bulk means: every row the user submits is packed into one AWX job. The playbook receives a structured list and iterates itself. If you need per-row parallelism, Ansible's native loop + async modules is the right tool — inside a single job, not across jobs.

Workflow clones

When a request against a workflow template launches, Fabrik does not invoke AWX's workflow launch endpoint directly against the template you registered. Instead, for every launch (initial submission and every relaunch), it:

Calls AWX's POST /api/v2/workflow_job_templates/{source}/copy/ to create an ephemeral clone of the workflow template, named __fabrik__<request-prefix>_<random>.
Attaches the user-selected APIC credential to each eligible job-template node on the clone.
Launches the clone — AWX snapshots the per-launch credential bindings into the workflow_job, so child jobs receive the credential.
After the workflow_job reaches terminal status, deletes the clone (a Celery task fires off the post-terminal hook in JobMonitor).
An hourly reaper (awx.cleanup_orphaned_workflow_clones) sweeps any clones the immediate hook missed — for example, after a worker crash or AWX outage.

Why clone instead of mutating the source? AWX does not cascade launch-time credentials from a workflow_job_template down to its child job-template nodes. Earlier versions of Fabrik worked around this by mutating the source template (associate → launch → disassociate) under a Redis lock. That mutation was visible to other consumers of the template and broke AWX-side relaunch (which re-snapshots from the post-cleanup config). Cloning per-launch is the AWX-native fix: the user's source template is never touched, and relaunch is just "clone again."

What you'll see in AWX UI. Workflow templates whose name starts with __fabrik__ are Fabrik-owned ephemeral entries. They appear during a workflow run and disappear within ~30–60 seconds of completion. Don't edit or rerun them from the AWX UI — they exist for one launch only.

Permissions impact. Fabrik's AWX user/token needs Workflow Admin on the org so it can create and delete workflow templates. See Connections → Required AWX permissions.

Template snapshots

When a user submits a request, Fabrik freezes a copy of the template's config onto the request (template_snapshot). Later edits to the template — schema changes, validation updates, approval toggles — do not retroactively affect requests that were already submitted.

This protects in-flight work from surprise behavior when someone edits a shared template mid-batch. The running request sees exactly the template it was submitted against.

Create. Any authenticated user can create a template.
Edit / delete. Only the creator or an admin.
Execute. Any user who can see the template can submit a request against it. Approval, if enabled, still runs.
Public templates. Created by admins or explicitly toggled; visible to everyone.

There's currently no per-template access-control list beyond public vs creator-only. Finer grain lives at the request/approval layer.

Usage statistics

Each template tracks execution_count, success_count, failure_count, and last_executed_at. These surface as badges on the Template Library cards — useful for spotting the templates everyone leans on, and the ones nobody touches.

Success and failure counts are incremented by the job monitor after each execution finishes; they reflect the AWX-reported outcome, not per-row results.

Troubleshooting

Template issues that come up often:

"Wizard returns zero templates." The token doesn't have permission to list job templates on that AWX. Check the AWX user's role on the relevant organization.
"My form field isn't reaching the playbook." Check the column name matches what the playbook expects, or set a mapping in variable_mappings. Remember: for multi-schema workflows, each schema has its own awx_variable_name — the entire row list goes under that key.
"Validation runs but doesn't fail the request." requires_validation is off. Turn it on, or accept that validation is advisory for that template.
"Check mode setting is ignored." The playbook's modules don't support check_mode. Check mode is an Ansible feature — Fabrik only passes the flag.
"Approvers don't see the request." The approver config uses user and group references set on the template. If you added users after requests were created, only new requests will route to the updated approver list — template_snapshot freezes the approver list at submission time.
"I edited the schema and an in-flight request still uses the old one." Working as intended — template_snapshot protects the request. The edit applies to new requests only.

Templates define what the user fills in. The next page — Validations — is about what's allowed in those fields: regex patterns, static lists, live query-backed lists, and how to share them across templates.