CMDB-Driven Patch Wave from ServiceNow

Make the ServiceNow CMDB the single source of truth that drives your patch waves. This blueprint queries the configuration items flagged as due for patching, runs your patch runbook against each one, and writes the outcome back to the CMDB so inventory always reflects what was actually patched. Instead of maintaining a separate patch list that drifts from reality, the CMDB defines the scope, controls concurrency, and stays continuously reconciled. This closes the gap between change management records and the servers in the field, giving infrastructure and platform teams an auditable, repeatable patch cycle triggered by their own change window.

How it works

1. A change window or external scheduler posts to the io.kestra.plugin.core.trigger.Webhook trigger (on_patch_window) to start the wave.
2. list_cis (io.kestra.plugin.servicenow.Get) queries the cmdb_ci_server table using the encoded ci_query input with fetchType: FETCH to pull the CIs due for patching.
3. patch_each_ci (io.kestra.plugin.core.flow.ForEach) iterates over outputs.list_cis.results with a concurrencyLimit of 2, capping how many servers patch at once.
4. For each CI, run_patch (io.kestra.plugin.core.flow.Subflow) runs the patch runbook named by patch_runbook_id with wait: true, so the wave blocks on each runbook completing.
5. update_ci (io.kestra.plugin.servicenow.Update) records the patch on the CI by sysId, clearing u_patch_due, stamping u_last_patched with now(), and adding work_notes referencing the Kestra execution.id.

What you get

• A CMDB-scoped patch wave where the inventory itself selects the servers.
• Controlled rollout with a concurrency cap to avoid patching everything at once.
• Automatic write-back to ServiceNow, so records reflect actual patch state.
• A full audit trail linking each CMDB update to a specific Kestra execution.

Who it's for

• Infrastructure and platform engineers running scheduled patch cycles.
• IT operations and ServiceNow administrators who own the CMDB.
• Security and compliance teams who need patch evidence tied to inventory.

Why orchestrate this with Kestra

ServiceNow can flag CIs and fire a webhook, but it is not built to fan out a runbook across servers, gate concurrency, retry a failed host, and reconcile state in one declarative flow. Kestra adds event-driven triggering, per-task retries, end-to-end lineage from CI selection through patch to CMDB write-back, and a single YAML definition you can version in Git. The ForEach concurrency control and Subflow wait semantics give you orchestration the CMDB's own scheduler cannot provide.

Prerequisites

• A patch runbook flow in the company.team namespace to call per CI.
• CMDB CIs in cmdb_ci_server carrying a patch-due flag your ci_query can match.

Secrets

• SN_DOMAIN: ServiceNow instance domain.
• SN_USERNAME: ServiceNow API username.
• SN_PASSWORD: ServiceNow API password.
• SN_PATCH_WEBHOOK_KEY: key guarding the webhook trigger.

Quick start

1. Set the four secrets above in your Kestra namespace.
2. Adjust the ci_query input to match how your CMDB flags patch-due servers.
3. Point patch_runbook_id at the flow that performs the patch.
4. Post to the webhook from your change window or scheduler to launch a wave.

How to extend

• Map u_patch_due and u_last_patched to your own CMDB schema fields.
• Raise or lower concurrencyLimit to tune rollout speed and blast radius.
• Add a notification task (Slack, email) to report per-wave results.
• Open a change request or incident in ServiceNow when a runbook fails.

Links

• Plugin documentation
• ServiceNow orchestration with Kestra