Update sets
The guards on a save, Auto-Insert, the checks that read a set before you ship it, and the deploy to your other instances.
Everything on this page is in the panel, and everything reads your instance through your own session. Nothing here runs until you ask for it.
The guard on saves into Default
A save that lands in Default cannot be migrated, and you usually find out later. The guard warns you at the save instead.
It recognises a save across the shapes ServiceNow actually uses: list edits, inline edits, the table API, the Service Catalog API, and a GraphQL call carrying a mutation. It reads the table out of the request rather than guessing it.
Then it decides. Capture is on, or the table is tracked, and you get a warning. The table is not tracked, and it stays quiet. Nothing has answered yet, and it asks.
Whether a table is tracked is a question about the hierarchy, not about one table. The walk goes
up through the ancestors and the nearest explicit answer wins; with no explicit answer, the
question is whether the hierarchy reaches sys_metadata. sysauto_script is the counterexample
worth knowing: it lives under sys_metadata and is not captured.
A click on a UI action cannot wait for the instance to answer, so that path fails safe. If the answer is not already known, the click is held rather than allowed.
Answers are cached per table for a week, and the guard writes one line to the log for every decision it makes, including the quiet ones, so the times it said nothing are auditable too.
It stays quiet on purpose for requests with no attributable table, which means the catalog runtime and the workspace GraphQL layer. A guard that fires on a request it cannot name is a guard people turn off.
You acknowledge once per set, per session.
Auto-Insert
Some tables the platform simply does not track. Auto-Insert catches a save on one of them and forces the record into your active set, using the platform's own update manager, run as a background script with your rights.
The switch is in the middle of the panel. Its three states are off, armed and paused, and a pause takes a number of minutes and resumes itself.
By default an already-captured record is skipped rather than written again, and counted under Skipped. The three tiles show this session, total tracked, and skipped.
Its limit is stated inside the product itself: it cannot capture what does not exist yet. It reacts to saves, so a record changed before you armed it is not captured retroactively. That is what Orphans is for.
Inspect set
What is actually in the set, read from sys_update_xml for the active set, newest first, with a
count beside the button.
From a row you can jump to the record, move selected entries to another set, or remove entries. If the active set id cannot be resolved, the panel says so rather than showing an empty list that looks like an empty set.
Orphans
Everything sitting in Default, filtered to you, and to the current application scope when one is selected.
Resolving your own login and the current scope is done over REST, falling back to a background script only when REST refuses. If your login cannot be resolved at all, the panel says it is showing every user's orphans rather than implying the list is yours.
Moving is offered only when the active set is a real, in-progress set. Each row also has a re-capture button, which pulls a newer version of that record forward into the current set.
Promote check
What the set needs and does not include. One background script does the whole pass: read every entry, parse the sys_id each one provides, scan the payloads for the sys_ids they reference, work out which of those are real configuration records, and find where each one is tracked.
What gets reported is deliberately narrow. A reference sitting in Default or in another in-progress set is a problem and is listed. A reference already in a completed set, or a baseline record that was never customised, is counted and hidden. A check that reports everything is a check nobody reads.
Each row has a Capture button that pulls that record into the current set, and you can capture several at once. On the Default set it refuses, and says to switch to a real one.
Set hygiene
What a reviewer would send back. It reads each record the set carries and flags:
| Flag | What it means |
|---|---|
| Debug output | A gs.print, gs.log, console.log or alert line left in |
| Hard-coded sys_id | A 32-character id in quotes inside a script |
| Hard-coded instance URL | A service-now.com address inside a script |
| Credentials | A password, secret, key or token assigned in a script |
| Synchronous Ajax | getXMLWait on a client-side table |
| Query in a loop | A query inside a loop |
| Writing to current | current.update() in a business rule |
| Writing in a before rule | A before rule writing another record |
| Empty script | An active record on a table where the script is the point |
| Inactive | The record is not active |
| No description | An empty description on a table where reviewers rely on it |
| Newer elsewhere | The same record captured more recently in another set |
A hard-coded sys_id on a client table is flagged as low rather than high, because the usual fix, a system property, does not exist client-side.
Every fix previews first: you see the before and the after, and confirm. Nothing is rewritten silently.
The pre-complete guard
Marking a set complete is the last moment anything can be fixed. When you save a set with the state set to complete, the promote check and the hygiene scan run, and their results are shown before the save goes through. It is read-only: it never edits the set for you.
The Insert guard
On an existing record, Insert and Insert and Stay do not update it: they create a copy. It is the easiest way to end up with two business rules of the same name, so the guard asks first. It covers the three ways in: the form button, the right-click menu on the form header, and the save chord CtrlShiftS.
Each guard has its own switch in the panel's Settings tab: Default-set guard, Insert guard and Pre-complete check. Turning one off leaves the other two alone.
The production guard
Mark an instance as production under Instances in the settings page, and every Update or Insert on it waits for you to confirm. It is off until you mark one. Guessing production from the host name is fine for a colour and wrong for a dialog, because a warning nobody asked for is one people learn to click through.
It matches on the save verb itself, so a UI action on the form, which carries its own id rather than a save verb, goes through untouched. Where the platform's submit cannot be wrapped the guard stays silent: a missed warning is the safe direction, and a held UI action is not. List inline edit is not covered yet.
Deploy to test
The arrow beside the active update set sends it to your other instances without leaving the page.
The destinations are the instances switched on as deploy targets under Instances in the settings page. One switch per instance, and it is never inherited from a default, because a default that said "deploy here" would mean every instance this browser has ever seen.
The run has two parts:
- Once, on this instance. The promote check and the hygiene scan, then marking the set complete and exporting it.
- For each target, in turn. Upload, preview, and commit, each target with its own preview gate.
A target that fails marks its own steps and the run moves on to the next one. A target you cancel stops the run. A dependency counts as present only when every target has it, and the gate row names the instances it is missing from.
If the set ends up committed on no target at all, whatever the reason (a host that does not answer, an upload the target ignored, a preview or commit error, the export failing, a cancel at the preview gate), it is put back to In progress and made your current set again, so you can fix the cause and deploy it once more. Once it is committed on at least one target it stays complete.
If the checks find something blocking, the deploy stops and says what. Each blocking row has a skip button, and Skip all takes the lot, for findings you have looked at and accepted: a record that is inactive on purpose, the one hard-coded URL that is correct. A skip lasts for that deploy only, and the log says how many were skipped instead of "No issues".
Making one instance both production and a deploy target asks first, whichever switch you turn on second.
Alignment across instances
Whether the same records really are the same on your other instances. The subject is an update set, or any customer update inside one. There is also a small chip beside a record title on a form, for checking one record on its own.
Which instances you list yourself, in the options page under Alignment check. Each one has a name, a host, and how to authenticate: the browser session, a stored credential, or automatic, which tries the session and falls back to the credential. The session is the only mode that works on an SSO-only instance and stores nothing; the credential is the only one that works when you have no session there at all.
The hard limit is the extension's own permissions: only *.service-now.com hosts can be reached.
An instance on a customer's own domain cannot be checked, and the message says exactly that
rather than failing vaguely.
What aligned means is worth being precise about, because the word is used loosely.
Two records are compared when they have the same table and the same sys_id. Nothing is matched by name: a record recreated by hand on the other side has a different sys_id and is a different record.
Both sides are read as stored values rather than rendered ones. Line endings are normalised and
trailing blanks stripped, and nothing else: no case folding, no whitespace collapsing. A version
counter may differ, and two numbers that are equal but written differently count as equal, though
0001 and 1 do not.
A deleted entry inverts the verdict. Absent on the other side is aligned, with the note "deleted on both". Still present there is not aligned.
Fields that always differ are ignored: the audit columns, the package and update-name columns, and, on flows only, the compiler and snapshot columns. Scope and class name are deliberately not ignored, because a record in the wrong scope is a real difference.
Reading is batched, three instances at a time, and this instance is read once however many targets you have. A set larger than four thousand entries reports itself as truncated rather than silently comparing part of it.
Flows get a real diff. For a flow or a subflow the two sides are drawn on a rebuilt Flow Designer canvas, steps matched by their own ids, each one tinted as the same, changed, only here, or only there. Legacy workflows are read through their published version, including the variables where a Run Script activity keeps its script.
One measured failure is carried out to you rather than hidden. On an instance where row-level security hides the condition and variable tables, they answer with an empty list rather than an error. The reader says the branches were not readable, instead of reporting that twelve conditions exist on one side only.