Run a Runbook on ServiceNow Change Approval

Close the loop between ITSM governance and real execution. When a ServiceNow change request is approved, this blueprint automatically drives the implementation: it marks the change in progress, runs your implementation runbook as a Kestra subflow, marks the change complete, and posts the result to Slack. The change record always reflects what actually happened, eliminating the manual hand-off between change approval and the engineer who runs the work. This is change automation, ITSM orchestration, and ServiceNow change_request lifecycle management driven directly from approval events.

How it works

1. The io.kestra.plugin.core.trigger.Webhook trigger (on_change_approved) listens for a ServiceNow approval callback, guarded by a secret webhook key.
2. mark_in_progress uses io.kestra.plugin.servicenow.Update to set the change_request row (matched by sysId) to the in-progress state (state: "-1") and writes a work_notes entry tagged with the Kestra execution.id.
3. run_runbook is an io.kestra.plugin.core.flow.Subflow that runs your implementation flow (the runbook_flow_id input) with wait: true, so the change only closes after the work finishes.
4. mark_complete updates the same change_request row to the closed-complete state (state: "0") with a completion work_notes entry.
5. notify posts to Slack via io.kestra.plugin.slack.notifications.SlackIncomingWebhook confirming the change was implemented and closed.

Shared ServiceNow credentials (domain, username, password) are injected once through pluginDefaults.

What you get

• Hands-off change implementation triggered the moment approval lands.
• A change_request record whose state and work notes mirror the real execution.
• Full execution lineage tying each ServiceNow change to a Kestra run.
• Slack visibility for every completed change.

Who it's for

• Platform and SRE teams that gate infrastructure changes through ServiceNow.
• ITSM and change managers who want approvals to actually trigger work.
• DevOps engineers tired of copy-pasting sys_ids into manual runbooks.

Why orchestrate this with Kestra

ServiceNow approves changes but does not run your Terraform, Ansible, or deployment steps. Kestra fills that gap: an event-driven webhook trigger fires implementation the instant a change is approved, wait: true subflows enforce ordering, retries and error handling keep partial failures visible (a failed runbook leaves the change in progress on purpose), and the whole pipeline is declarative YAML you can version and review. You get full lineage from approval to execution to record update, something ServiceNow's own workflow engine cannot orchestrate across your tooling.

Prerequisites

• A ServiceNow instance with API access to the change_request table.
• An implementation runbook flow to call (defaults to terraform-ansible-argocd-chain).

Secrets

• SN_DOMAIN: ServiceNow instance domain.
• SN_USERNAME: ServiceNow API username.
• SN_PASSWORD: ServiceNow API password.
• SN_CHANGE_WEBHOOK_KEY: key guarding the webhook trigger.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the secrets above to your Kestra namespace.
2. Configure a ServiceNow business rule or flow to POST the change sys_id to the webhook on approval.
3. Point runbook_flow_id at the flow that implements the change.
4. Approve a change request and watch the record advance automatically.

How to extend

• Swap the Slack step for Microsoft Teams, email, or PagerDuty notifications.
• Add a rollback subflow on failure so a failed change reverts and reopens.
• Map your instance's specific change_request state model instead of -1 / 0.
• Branch on change category to call different runbooks per change type.

Links

• Plugin docs
• ServiceNow orchestration with Kestra