Templates
Templates are saved, reusable option sets for a workflow — every selection from a wizard’s review step (servers, files, and options) captured under a name, so a recurring operation can be re-run without stepping through the wizard again.
Templates currently support Data Migration and Data Refresh. The Templates section in the navbar lists every template you can see, grouped by workflow.
Sharing and permissions
- A template is shared by server access: it is visible to everyone who can access both its source and target servers, not just the person who saved it.
- Only the template’s owner (or an admin) can delete it.
- Template names are unique per owner and workflow — saving again with a name you already used updates your existing template. Two different users can each have a template with the same name.
- Saved selections are never trusted on replay: every load, verify, and run re-validates them against the live servers and your current access. If you lose access to either server, the template disappears from your list.
Templates never store secrets. EAR keys in particular are not saved — the AWX roles fetch them from 1Password at run time (see Verify below).
Creating a template
On the Review & confirm step of a supported wizard, use the Save as template card: enter a name and click Save template. Everything on the review step is captured — for a migration that includes the sync-back directories, target-host options, flags, and pre/post script schedules; for a refresh, the backup option, flags, and the specific source backup when one was chosen.
Using a template
Open a template from the list to walk through its three pages:
1. Overview
Shows every parameter the template will run with: the client, both hosts (with production badges), the files involved, and all saved options. For a refresh template, the Overview also looks up the data host and shows the backup to copy from concretely: a pinned backup’s current size and date, or — with the default Latest full backup — the path, size, and date of whichever backup is newest right now (each run re-resolves the newest backup at launch and pins its exact path into the AWX job). From here you can:
- Verify — continue to the pre-flight checks.
- Edit in wizard — load the template into its workflow wizard, landing on the review step with every setting re-validated. Stale settings are cleared with a visible warning (a missing file drops you back to the file picker to re-select). Use this to change selections, then save again under the same name to update the template.
- Delete — owner or admin only.
2. Verify
Runs pre-flight checks against the live servers and shows each result as pass, warning, or failure. Any failure disables the Run step; warnings allow it but deserve a look. Checks include:
| Check | What it confirms |
|---|---|
| AWX job template | The workflow’s AWX template is configured in the portal. |
| Client | The saved client group still exists and is available to you. |
| Deploy chain / Refresh host | The receiving host is still a valid deploy-chain target for the providing host. For a refresh this also fails if the refresh host has since become a production server. |
| Files | The saved files still exist on their hosts. |
| Disk space | The receiving host has room for the transferred file (plus the backup copy when backup is enabled), shown with the same disk-usage card as the transfer flows. Fails when space would run out, or when the run would exceed the disk-capacity policy’s hard limit; warns when it would only cross the acknowledgement threshold, which Run then asks you to confirm. |
| Encryption (EAR) | If the target file is encrypted, its EAR key actually resolves in 1Password — a missing key would otherwise fail mid-job when the file is reopened. The check resolves the template’s saved 1Password override when one is set, otherwise the per-host convention entry (fms-ear-key_<host>). Warns (rather than fails) when the portal can’t check; the job fetches the key itself at run time. Note that a passcode filed by File Encryption does not satisfy this check: it is a file-specific entry in a separate vault, and neither this check nor the job looks there. |
| 1Password overrides (when set) | Each saved override entry (DMT credentials / EAR keys) actually resolves for the automation. Fails when the entry is missing, a required field is unreadable or empty, or the vault has not been shared with the automation user. |
| Source backup (refresh, when a specific backup is saved) | The pinned backup still exists on the data host — backups rotate out, so a template that names one goes stale on its own. When found, its exact size feeds the disk-space check. |
| Container directories (migration) | Saved sync-back directories still exist on the data host. |
| Script schedules (migration) | Saved pre/post-migration schedules are still configured on the data host. |
| Flags | Unknown flags are flagged as warnings; they are ignored at launch. |
Use Re-run checks after fixing anything. To update stale selections, go back and use Edit in wizard.
3. Run
Launches the job with the saved options. Before launching, the portal re-checks the essentials server-side (access, client, target validity, schedules) even if you skipped Verify.
- Production targets (migration): the Run button is red and a click-through confirmation modal appears — same as the wizard.
- Production targets (refresh): never allowed; the run is refused outright.
- Admin debug panel: staff users see a collapsible AWX extra vars panel showing the exact payload the run will submit — rendered from the same code path as the launch itself.
On success you are redirected to the same job output page as the wizard, and the operation is recorded in History as usual.
While a Verify, Edit in wizard, or Run action is working (these SSH into the servers and can take a few seconds), the page’s other buttons are disabled to avoid double-submits.