Legacy JSON Editing

If you installed SN Utils before v10, any slash commands and switches you had back then are preserved under the legacy keys slashcommand_legacy and switch_legacy (older installs may also have slashsswitches). SN Utils keeps Monaco JSON editors for these grandfathered entries under Manage > Advanced > Legacy JSON Editing, so your existing work keeps working and you can edit it in place for as long as you want.

The editors are always mounted — even on a browser profile that has no legacy data — so you can paste a grandfathered JSON backup and Save to restore it (for example after reinstalling, switching machines, or accidentally clearing storage). A local snapshot is captured before every save.

Legacy JSON Editing exists only for pre-v10 data. The editors read and write the legacy storage keys and nothing else.

New custom commands and switches are a Pro feature and are created and edited on the form-based Commands and Switches tabs — there is no raw-JSON path for modern custom entries by design. That keeps inputs validated, names consistent, and cloud sync predictable.

Legacy entries live in this browser only and do not sync across devices. The Pro Commands and Switches tabs add cloud sync, packs, and a form UI on top of the same runtime behavior — so if you run SN Utils on more than one machine or want to share command sets, Pro buys you real convenience rather than an artificial gate.

If you live in these editors, a Pro subscription is probably worth it — and it helps keep SN Utils funded. No pressure.

Where to find it

From anywhere in ServiceNow, type /manage or click the gear icon in the popup header. On the Manage page, open the Advanced tab. You will see two sections:

Legacy JSON Editing — Monaco editors for grandfathered slash commands and switches, always available.
Data Snapshots — local rescue backups, described further down.

Legacy commands editor

Writes to slashcommand_legacy. Root shape is an object keyed by command name:

{
  "myinc": {
    "url": "/now/nav/ui/classic/params/target/incident_list.do%3Fsysparm_query%3Dshort_descriptionCONTAINS$0",
    "hint": "Search my incidents",
    "fields": "number,short_description"
  }
}

url is required. $0, $1, ... are substituted with arguments, and $sysid with the selected row's sys_id. Other recognized fields:

hint — short description shown in the command palette
fields — comma-separated list of columns to show in list results
overwriteurl / overwrite_url — replaces the instance URL entirely (useful for absolute URLs)
description, category — optional metadata

Unknown fields are preserved; the schema allows additional properties.

Legacy switches editor

Writes to switch_legacy (falling back to slashsswitches on very old installs). Root shape is an object keyed by switch name — not an array. This is the legacy shape; the modern Switches tab uses an array of objects internally, but you do not edit that shape here.

{
  "mine": {
    "filter": "^assigned_to=javascript:gs.getUserID()",
    "description": "Limit list to records assigned to me"
  },
  "pinned": {
    "filter": "^sysparm_filter_pinned=true",
    "description": "Only pinned records"
  }
}

Recognized per-entry fields: filter, description, urlparam. The key name is the switch token users type after a dash (for example -mine).

Convert to Custom

When legacy data is present, the notice at the top of Legacy JSON Editing shows a Convert to Custom button (Pro). Clicking it opens a preview modal with:

How many legacy commands will land in slashcommand_custom
How many legacy switches will land in switch_custom
The first few keys from each bucket, so miscategorization (for example, switch-like intent pasted into the commands editor) is obvious before you confirm

Conversion behavior:

A pre-convert snapshot is captured in IndexedDB automatically.
Legacy entries are merged into slashcommand_custom and switch_custom. Existing custom entries take priority on key conflicts.
Legacy keys are kept as a local backup. You can continue editing them here, or remove them explicitly via Delete legacy backup now once you're confident the modern entries look right.

After a successful convert, the modern entries are what the Commands and Switches tabs show, and they participate in Pro cloud sync.

Save behavior

Each editor has an explicit Save button (no silent auto-save). Save runs in this order:

JSON.parse — if the JSON has a syntax error, the editor shows a red banner and does not write.
Structural validation — if entries are missing required fields (for example url on a command), you are asked whether to save anyway.
A pre-raw-save snapshot is captured in IndexedDB.
The parsed value is written to the corresponding legacy key in chrome.storage.local.

Each editor also has a Reload button that re-reads the current storage value (with confirmation if there are unsaved edits). If another part of the extension writes the same legacy key while you have unsaved edits, a banner appears above the editor with a Reload link — your in-flight edits are not overwritten until you explicitly Save or Reload.

Data Snapshots

Every destructive action captures a local snapshot in IndexedDB (database name snuDataSnapshots). Snapshots are purely local — they do not sync to the cloud, and they do not count against the chrome.storage.local 10 MB quota.

Snapshots are created automatically in these situations:

Before legacy conversion — pre-convert
Before login or account-switch resync — pre-login-wipe
Before manual legacy deletion — pre-legacy-delete
Before every legacy JSON save — pre-raw-save

You can also create a manual snapshot any time via the Data Snapshots panel.

For each snapshot the panel lists the timestamp, the trigger, the captured key counts, and four actions:

Inspect — view the captured JSON in a read-only modal.
Restore (merge) — add back entries from the snapshot that are missing in your current data. Existing entries are kept as-is. Safe and non-destructive.
Restore (replace) — overwrite the current value for each captured key with the snapshot's copy. Use this if current data is clearly corrupt.
Delete — remove the snapshot.

Pruning keeps the 20 most recent snapshots and anything under 90 days old, whichever set is larger.

Restoring from a JSON backup

If you have a grandfathered JSON backup (an export you saved yourself, a copy from another browser, a teammate's snippet, or content recovered from a Data Snapshot elsewhere), paste it into the relevant editor and click Save. Behavior:

The commands editor accepts the object-keyed shape described above and writes to slashcommand_legacy.
The switches editor accepts the object-keyed shape and writes to switch_legacy.
A pre-raw-save snapshot is captured first, so the prior storage value (even if empty) is recoverable from the Data Snapshots panel.
After a successful paste-and-save you can leave the entries as legacy, or run Convert to Custom to merge them into the modern format and pick them up in the Commands and Switches tabs.

This is the intended rescue path when the legacy keys are empty on a browser but you have the JSON elsewhere. It does not grant a raw-edit path for modern custom data — the editors only ever touch the legacy keys.

Troubleshooting

I broke my legacy JSON after a paste. Open the Data Snapshots panel, find the pre-raw-save snapshot from just before the paste, and click Restore (replace). The pre-paste value was captured automatically.

My commands disappeared after signing in. A pre-login-wipe snapshot is captured before the extension clears sync state for a fresh pull. If the pull did not bring back something you had locally, restore it from that snapshot.

Schema warnings appear as red underlines. The JSON schema is intentionally conservative: url is required on legacy commands. Unknown properties are allowed, so custom fields from very old installs won't be flagged. You can choose to Save anyway when there are structural warnings — the snapshot still captures the previous value first.