AnsibleByExample

Ansible Orchestrator Example: Closing an ITSM Ticket from a Workflow

Beginner
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

Red Hat's upcoming Automation Orchestrator (announced for Q3 2026 at Red Hat Tech Day Netherlands 2026, Bunnik) runs event-driven, AI-assisted remediation on a single governed canvas, but the last mile is still boring and important: closing the ITSM ticket once the fix is verified. Here's a minimal example of the ServiceNow close step as it would appear inside an AAP job template task, plus the config fields that matter.

---
- name: Close ITSM ticket after remediation
  hosts: localhost
  gather_facts: false
  vars:
    servicenow_instance: "{{ lookup('env', 'SN_INSTANCE') }}"
    incident_number: "INC0038291"
  tasks:
    - name: Close ServiceNow incident with resolution notes
      servicenow.itsm.incident:
        instance:
          host: "{{ servicenow_instance }}"
          username: "{{ lookup('env', 'SN_USERNAME') }}"
          password: "{{ lookup('env', 'SN_PASSWORD') }}"
        number: "{{ incident_number }}"
        state: closed
        close_code: "Solved (Permanently)"
        close_notes: >-
          Remediated CVE-2024-6387 (regresshion) via AAP job template
          openssh-patch-rolling. 12 hosts patched across prod/staging/dev
          in 3 batches of 4, zero downtime, all health checks passed.
        caller: "automation-orchestrator"
      register: sn_close_result

    - name: Report ticket close status back to the orchestrator canvas
      ansible.builtin.debug:
        msg: "Ticket {{ incident_number }} closed: {{ sn_close_result.record.state }}"

What this does

This is the final task in the 5-step Orchestrator pipeline: alert ingestion, EDA rulebook trigger, AI analysis and recommendation, human approval, and automated remediation at scale. The servicenow.itsm.incident task runs after the remediation job template reports success, setting the incident to closed with a close_code and close_notes string that documents exactly what changed — host count, batch strategy, and outcome. In the live CVE-2024-6387 demo at the event, this step ran in 2.1 seconds, closing INC0038291 after the rolling patch across 12 hosts completed with all health checks green.

In the Orchestrator's actual workflow, ticket creation and closure are triggered by webhooks rather than static playbook vars: an initial ServiceNow webhook (step 3 in the demo) POSTs to the EDA webhook endpoint using an auto-generated API key, and the close call is fired the same way once remediation finishes — no operator has to touch ServiceNow directly. The credentials shown above as env lookups map to whatever credential object AAP resolves for the ServiceNow instance at execution time.

Notes / Gotchas

  • Match the close code to your ServiceNow instance's picklist. "Solved (Permanently)" is a common default, but instances customize this field — a mismatched value will fail the task, not silently skip it.
  • The close step should never fire before the human review gate passes. In the reference workflow, the Human Review step has a configurable list of usernames to notify, a custom approval message ("Please approve this deployment to production"), a 1-day default timeout, and an explicit on-timeout action of "Fail the workflow" — there is no silent auto-approval path, so make sure your close task is gated the same way in your own pipeline.
  • Keep close_notes machine-generated and specific. Free-text summaries pulled from the remediation job's own output (host count, batch size, health-check result) are what make the audit trail useful later — don't hardcode a static string across different incidents.
  • This is one task, not the whole workflow. The full pipeline also includes MCP-driven investigation (Splunk Query, Splunk Alert Search, Splunk Saved Search, ServiceNow CMDB Lookup) and inventory correlation before remediation ever runs; the close task only fires once that upstream work has already succeeded.

Closing the ticket is a small task definition, but it's the piece that makes an AI-assisted remediation workflow auditable end to end — the ticket record, not just the job log, proves what ran and who approved it.

References

All Tutorials