background-script-execution
Background Script Execution
snow_execute_script is the most-recommended tool in this catalog and the least explained. It does not use ServiceNow's Scripts - Background module. It ships its own transport, and knowing which of two paths your call took is the difference between reading a real result and reading a placeholder.
The two paths
| Sync path | Fallback path | |
|---|---|---|
metadata.method |
sync_rest_api |
sysauto_script_with_trigger, or scheduled_job_pending |
| How it runs | POST to a Scripted REST endpoint Serac installed; the operation evaluates your script inline and returns the result in the HTTP response | Creates a sysauto_script job plus a sys_trigger row set to fire two seconds out, then polls sys_properties for a marker the job writes when it finishes |
| Typical latency | 1–3s | 4s to the full timeout (default 30s) |
| You get output | Yes, in the response | Only if the poll caught the marker before it gave up |
Every call tries the sync path first. It falls back the moment the sync POST does not return a usable body — and that includes the case where your script ran and threw, because the endpoint answers a thrown script with HTTP 500 and the client treats any non-2xx as "endpoint didn't work". So a script with a bug in it can be executed up to three times: once by the sync POST, once by the retry after the endpoint is re-verified, once by the scheduled job. Assume a failing script is not executed exactly once, and never let a script that mutates data be the thing you debug through this tool. Get it right in a read-only form first.
The endpoint Serac installs
The first call against an instance deploys a Scripted REST API. Two records, both created through the Table API: