Read change requests on schedule or webhook, run the matching runbook, update the ticket with execution links, close on completion. Open incidents when production flows fail. Pull CMDB CIs to scope patch waves. The ticket fires the flow, both sides record the audit.
ServiceNow holds the audit and the human process. Kestra holds the execution. The plugin closes the loop: tickets fire flows, flows update tickets, CMDB scopes the work, audit lives on both sides cross-referenced. The copy-paste between the runbook doc and the change record disappears.
A scheduled flow runs servicenow.Get against the change_request table, filtered by state=new and category=standard. A ForEach iterates the result. Per ticket, an If task routes to the right runbook subflow based on the template or category. The runbook executes against the right environment with the ticket fields as inputs. The flow updates the ticket with the execution URL and the result.
Configure a ServiceNow Business Rule to POST to a Kestra Webhook trigger when a change_request matching the filter is approved. The trigger fires the flow with the full ticket payload as trigger.body. No polling lag, no missed tickets. The runbook starts the moment the ticket transitions to approved, with the change record number in the execution context.
Every step of the runbook flow updates the ticket. Start: servicenow.Update sets state=work_in_progress, work_notes=Started by Kestra. Per task: servicenow.Update appends per-step progress as work_notes. End: state=closed_successful or closed_incomplete, with the execution URL and result summary in the comments. The ticket becomes the single audit record.
A production flow's errors branch fires servicenow.Post against the incident table, with the failing task, the execution URL, recent logs, and assignment_group pointed at the right team. The incident sys_id flows forward. A follow-up servicenow.Update closes the incident when on-call clears it, with resolution notes linked back to the Kestra execution that triggered the fix.
When a change request hits a specific application, the runbook needs to know which servers, databases, and load balancers are involved. servicenow.Get against cmdb_ci_appl with a relationship query returns the linked CIs. The flow uses that list to scope its operations: which hosts to patch, which database to migrate, which load balancer to drain. The CMDB stays the source of truth for the blast radius.
Every infrastructure change orchestrated by Kestra writes to a ServiceNow change_request. Every ticket records the Kestra execution ID in a custom field. SOX, ISO 27001, or internal audit asks who changed what and when; both systems answer with cross-references. The flow execution links to the ticket; the ticket links to the flow. The audit story writes itself.
Patterns enterprise platform teams run in production today. Each one shows the flow end to end, with the real plugin classes in play.
A user opens a change_request with category=standard, template=restart_app_service. ServiceNow's Business Rule POSTs to the Kestra Webhook trigger on approval. The flow parses the template from the ticket, runs the matching subflow (restart the app server in the right region with the right credentials), captures logs as task artifacts, updates the ticket with state=closed_successful and the execution URL. No human in the loop for routine ops, full audit on both sides.
The ticket's template field selects which subflow to run. New templates add a new subflow, not a new flow.
work_in_progress at start, work_notes per task, closed_successful at end. The ticket reflects real-time progress.
Six months later, audit looks at the ticket and clicks straight to the Kestra execution with full task logs.
For pre-approved templates, the only human action is the original ticket approval. Everything after is the flow.
A scheduled production flow fails. The errors branch fires servicenow.Post against the incident table with the failing task name, the execution URL, an excerpt of recent logs, severity calculated from the impacted CIs (looked up via servicenow.Get on cmdb_ci_appl_relationship), and assignment_group routed to the application owner. The incident sys_id is captured. The on-call team gets the ticket with the right context, the right severity, and the right routing.
Tier-1 applications produce P1 incidents. Sandbox apps produce P3. The flow looks up the CI tier and routes accordingly.
The cmdb_ci_appl record names the owning team. The incident lands on the right group without a human routing it.
Failing task, execution URL, recent logs, impacted CIs all live in the incident body. The on-call does not start with a blank page.
A monthly patch change_request opens with category=patching, application=billing. On approval, the flow fires. servicenow.Get against cmdb_ci_appl_relationship pulls every CI linked to the application. A ForEach iterates the CIs; per CI, the patching subflow runs (snapshot, patch, health check, rollback on failure). After all CIs are patched, the flow updates the ticket with a results summary: how many CIs patched, how many rolled back, the per-CI execution URLs.
Adding a host to an application means updating the CMDB relationship. The next patch wave picks it up automatically.
If one CI's health check fails, the subflow rolls back that CI only. The wave continues for the rest.
The closing update lists every CI, the per-CI execution URL, success or rollback. The ticket is the post-mortem artifact.
A weekly reconciliation flow scans the actual infrastructure (AWS via aws.cli, Proxmox via vm.List, Kubernetes via kubectl.Get) and lists the live resources. servicenow.Get against cmdb_ci pulls the declared CIs. A Python diff task highlights CIs in ServiceNow but missing from reality (auto-create incident via servicenow.Post) and resources in reality but missing from CMDB (auto-create CI via servicenow.Post against cmdb_ci). The CMDB stays trustworthy without manual quarterly audits.
A new server added to AWS but not in CMDB triggers a CI creation. A CMDB record with no live instance opens an incident.
Reality-found additions get a review-needed tag in the auto-created CI. CMDB-only entries open incidents for investigation.
SOX or ISO audit shows up to weekly reconciliation reports, not a frozen point-in-time snapshot.
One blueprint per use case above. Copy the YAML, set your ServiceNow instance URL and credentials, point at your tables, ship it.
Listens for ServiceNow Business Rule webhooks on change_request approval. Dispatches the matching subflow based on the template field. Updates the ticket through the work via servicenow.Update calls and closes with the execution URL.
On a production flow failure, looks up the affected application's owner and tier from cmdb_ci_appl, calculates severity from the tier, and opens an incident with the full context routed to the right assignment group.
Listens for patch-category change requests, pulls every CI related to the application from cmdb_ci_appl_relationship, runs the per-host patching subflow per CI, updates the ticket with per-CI status, closes with a summary.
| Capability | | ServiceNow Flow Designer | ServiceNow Orchestration (EE add-on) | Custom REST polling + scripts |
|---|---|---|---|---|
| Trigger flows from approved tickets via webhook | Business Rule + Kestra Webhook trigger, real-time | In-platform only, scoped to SN apps | In-platform with paid orchestration packs | Custom polling code |
| Run an arbitrary runbook against any infrastructure | 1300+ plugin tasks, dispatched from a Subflow | SN-native steps; external action via MID server only | Predefined orchestration content packs | Whatever you write |
| Two-way audit: ticket has execution, execution has ticket | servicenow.Update on each step + execution links | Flow logs internal to SN | Orchestration history internal to SN | Manual correlation |
| CMDB lookup as a flow task | servicenow.Get on cmdb_ci, cmdb_ci_appl_relationship | In-platform GlideRecord | In-platform GlideRecord | Custom HTTP |
| Open incident from flow failure | servicenow.Post in errors branch | Not in scope (no external flow) | Limited to orchestration scope | Custom code |
| Bidirectional drift detection CMDB vs reality | Scan + servicenow.Get + diff + Post/Update in one flow | Service Mapping / Discovery (separate ITOM product) | Discovery + orchestration packs | Custom reconciliation |
| Approval gate before destructive runbook | Pause + resume + servicenow.Update on approve | SN approval rules native | SN approval rules native | Custom approval UI |
| Self-hosted, air-gapped Kestra reaches SN behind MID | Kestra workers connect via MID server or direct HTTPS | SN-hosted | SN-hosted | Custom |
| Chain ServiceNow with Terraform, Argo CD, dbt, Slack | Outputs flow into any plugin task | SN ecosystem only | Orchestration packs, SN-centric | Custom integration code |
Find answers to your questions right here, and don't hesitate to Contact Us if you couldn't find what you're looking for.
Ticket-driven orchestration with ServiceNow
How to configure Business Rules, wire webhooks to Kestra triggers, and write runbooks that update tickets through the work.
Chain ServiceNow with Terraform
The common pattern: a change request approval fires a Terraform apply, the ticket gets the plan output, the ticket closes with the apply result.
ServiceNow plugin reference
Every ServiceNow task (Get, Post, Update, Delete) with copy-ready YAML and full property reference.
Read approved change requests, dispatch the matching runbook, update the ticket through every step, close with the execution URL. Open incidents from production flow failures with CMDB-driven severity. Reconcile CMDB drift weekly. Open source, self-hosted, event-driven.
