Update a custom ServiceNow table

Keep a custom ServiceNow table continuously in sync with an external data source. This flow pulls records from an HTTP API and upserts them into a ServiceNow custom table, updating rows that already exist and inserting the ones that do not. It solves the recurring ITSM integration problem of mirroring product, asset, or reference data into ServiceNow without manual imports or brittle one-off scripts, using the ServiceNow Table API for every read and write.

How it works

1. A io.kestra.plugin.core.trigger.Schedule trigger fires daily on the 0 6 * * * cron.
2. fetch_products runs a io.kestra.plugin.core.http.Request GET against the source API and returns a list of records in body.products.
3. iterate_products, a io.kestra.plugin.core.flow.ForEach, loops over each record.
4. For each item, check_existing_product (io.kestra.plugin.servicenow.Get) queries the product_data table for matching fields (title, description, price, category).
5. if_product_exists, a io.kestra.plugin.core.flow.If, branches on check_existing_product.size > 0.
6. If the record exists, update_product_in_servicenow (io.kestra.plugin.servicenow.Update) updates it by sysId. Otherwise post_product_to_servicenow (io.kestra.plugin.servicenow.Post) inserts a new row.

What you get

• A repeatable upsert pipeline that prevents duplicate ServiceNow records.
• Daily, hands-off synchronization of external data into a custom table.
• Per-record branching so updates and inserts are handled correctly.
• Field-level control over what lands in ServiceNow.

Who it's for

• ITSM and ServiceNow administrators maintaining reference or asset tables.
• Platform and integration engineers wiring external systems into ServiceNow.
• Operations teams that need trustworthy, current data inside ServiceNow.

Why orchestrate this with Kestra

The ServiceNow scheduler runs jobs inside the platform but cannot reach out, pull from an arbitrary HTTP API, branch per record, and retry the failed call in isolation. Kestra drives the whole cross-system flow from declarative YAML: event and schedule triggers start the run, task-level retries recover transient API failures, and every execution is captured with full lineage and replayable logs. You get one auditable definition spanning the source API and ServiceNow instead of scattered scripts.

Prerequisites

• A reachable ServiceNow instance with the Table API enabled.
• A custom table named product_data (or your own) with the target columns.
• A user or service account with read and write permissions on that table.

Secrets

• SN_DOMAIN: your ServiceNow instance domain.
• SN_USERNAME: the ServiceNow account username.
• SN_PASSWORD: the ServiceNow account password.

Quick start

1. Add the SN_DOMAIN, SN_USERNAME, and SN_PASSWORD secrets to your Kestra environment.
2. Confirm the product_data table and its fields exist in ServiceNow.
3. Add the flow and run it manually to validate the upsert behavior.
4. Let the daily schedule keep the table in sync.

How to extend

• Point fetch_products at your own API and remap the data fields.
• Change the matching logic in check_existing_product to a unique key.
• Adjust the Schedule cron or swap it for an event-based trigger.
• Add notifications or error handling around the write tasks.

Links

• Plugin docs: https://kestra.io/plugins/plugin-servicenow
• Orchestrate ServiceNow with Kestra: https://kestra.io/orchestration/servicenow