Scan ServiceNow Incidents and Fan Out Remediation Subflows

Turn a ServiceNow incident queue into an automated remediation pipeline. This Kestra blueprint scans your ServiceNow instance on a schedule, uses the KV Store as an incremental cursor so every incident is processed exactly once, and launches one subflow execution per new ticket. Each ticket becomes its own execution with its own logs, retries, and status, so a single stuck remediation never blocks the rest of the queue.

How it works

1. The every_15_minutes trigger (io.kestra.plugin.core.trigger.Schedule) starts a scan every 15 minutes.
2. The lastCheckDate task (io.kestra.plugin.core.kv.Get) reads the serviceNowLastPollDate cursor from the KV Store, tolerating a missing key on the very first run.
3. The formatTimestamp task (io.kestra.plugin.core.debug.Return) rewrites the cursor into a gs.dateGenerate fragment that the ServiceNow query encoder accepts.
4. The fetchOpenTickets task (io.kestra.plugin.core.http.Request) calls the ServiceNow Table API for incidents in state 1 (New) created after the cursor, authenticated with a basic auth token and capped at 100 records per scan. taskCache avoids refetching identical queries.
5. The getTicketDetails task (io.kestra.plugin.core.flow.ForEach) iterates the result array and the nested processTicket task (io.kestra.plugin.core.flow.Subflow) launches servicenow-incident-ansible-remediation with the ticket number, short description, open date, sys_id, and category.
6. The updateLastCheckDate task (io.kestra.plugin.core.kv.Set) advances the cursor to now, in UTC, so the next scan only sees newer tickets.

What you get

• Incremental polling with a durable KV Store cursor, no duplicate processing after restarts.
• One isolated execution per incident with independent logs, retries, and state.
• A queryable audit trail linking every ServiceNow ticket to the exact execution that handled it.
• A pattern that works without any webhook or MID Server changes on the ServiceNow side.

Who it's for

• IT operations teams who want incidents remediated minutes after they are opened.
• Platform engineers replacing cron plus shell scripts with observable, versioned automation.
• ServiceNow admins who cannot open inbound webhooks but can allow outbound API polling.

Why orchestrate this with Kestra

A cron job that polls ServiceNow gives you no per-ticket visibility, no retry semantics, and a cursor stored in a fragile local file. Kestra gives you a declarative schedule, a durable KV Store for the incremental cursor, fan-out to isolated subflow executions, and a UI where each ticket's remediation can be inspected, retried, or replayed independently. The parent scan and each child remediation are linked in the execution graph, so lineage from queue to fix is automatic.

Prerequisites

• A ServiceNow instance with the Table API enabled and a user allowed to read the incident table.
• The companion servicenow-incident-ansible-remediation flow deployed in the same namespace.
• Set the serviceNowInstance variable to your instance name (the your-instance part of your-instance.service-now.com).

Secrets

• SERVICENOW_TOKEN: base64-encoded user:password pair used as the basic auth token for the Table API.

Quick start

1. Add the SERVICENOW_TOKEN secret to your Kestra namespace.
2. Replace the serviceNowInstance variable with your real instance name.
3. Deploy the companion remediation subflow, then this flow.
4. Run it once manually; the first scan initializes the cursor and processes the current queue.
5. Watch the Executions view fill with one child execution per new incident.

How to extend

• Tighten the sysparm_query to a specific assignment group, priority, or CI class.
• Raise sysparm_limit and add pagination for high-volume queues.
• Route different categories to different subflows with a io.kestra.plugin.core.flow.Switch task before the fan-out.
• Add concurrencyLimit on the ForEach to throttle how many remediations run at once.
• Swap polling for the push pattern: a io.kestra.plugin.core.trigger.Webhook trigger fed by a ServiceNow Business Rule outbound REST call.

Links

• ServiceNow plugin docs: https://kestra.io/plugins/plugin-servicenow
• KV Store documentation: https://kestra.io/docs/concepts/kv-store
• Subflow task: https://kestra.io/plugins/core/tasks/flow/io.kestra.plugin.core.flow.subflow