Script Runs

What it does

Something changed and nobody owns up to it. A field is empty, a queue is suddenly full, three hundred records have the wrong owner.

Somebody almost certainly ran a background script. ServiceNow wrote down exactly which one, who ran it, when, how long it took and what it printed - and then put no screen anywhere in the product to look at it.

This is that screen.

What you actually get

Every background script run in your window, with the things that let you find the one that matters: who ran it, when, how long it took, and what kind of calls its source contains - deletes, writes, suppressed business rules, platform tables touched, system properties set.

On the development instance this was built against, 287 of the most recent 400 runs contained a call that could change data. Filtering to just the deletes brings that to a list you can actually read.

Then open one and read the script exactly as it ran, and everything it printed.

Two roles, and why that matters

Seeing that a script ran is a much smaller thing than reading what it contained.

A background script is written by somebody in a hurry with administrator rights. It can hold an endpoint, a token that was pasted in, or a customer's name in a where-clause, and its output can hold the rows it printed. None of that passed through an access control on the way into the history table.

So the list and the source sit behind different roles. Whoever is investigating an incident can be given the first without being handed the contents of every script an administrator has ever run.

Read the retention screen once, on day one

This is the part that makes it urgent rather than merely interesting.

ServiceNow does not keep this history. A clean-up rule deletes it after a set age - seven days on a default instance. After that the record of what was run is gone, and nothing can recover it.

That figure is a setting, so this reads the rule from your instance and tells you your real number rather than printing the default and hoping.

What it will not do

It cannot run a script. There is no execute path in this application at all • not disabled, not behind a flag. A tool that reports what was executed and can also execute is a different and far riskier thing to install.

It cannot undo one. What a script did is done. Reversing it is what the platform's own rollback machinery is for.

It will not change your retention. It reads the rule and reports it. Keeping every script anybody runs, with its full source and output, for longer is a storage decision and a data-protection decision at once, and it belongs to whoever owns the instance.

It stores nothing. No tables ship with it. Keeping a second copy of every script and its output would be a liability rather than a feature.

Where it stops

It reads at most 400 runs in one go and says so plainly when it has. A window with more than that is a different conversation, and walking all of it is how a diagnostic becomes the outage it was opened to investigate.

A risk flag says the source contains that kind of call. It is a reason to read the script, not a verdict on what the script did.