Flows and catalog items

Reading a flow from its own tables, and answering what breaks if you change a catalog variable.

Two readers, for the two parts of the platform that are hardest to read by hand.

The variable explorer

/vex on a catalog item answers one question: if I change this variable, what breaks?

The scope is the feature. Everything starts from one catalog item and never widens. It reads the item, its variables, its variable sets, its client scripts, its UI policies and their actions, and the script includes and business rules those actually name. Business rules are restricted to the request tables, because a rule on incident is not this item's business.

On a portal page, where the address has a different shape, it asks the instance to confirm the record really is a catalog item before opening, so a wrong page is a visible message rather than a window that silently does not open.

Two kinds of link, and they are not worth the same

Structural links come from fields the platform maintains itself: a client script or a policy action that points at a variable by reference. Those cannot be wrong.

Textual links come from reading a script body and finding the variable's name in it. Those can be wrong, so every one carries the line it was found on, and the panel shows you that line.

When a script cannot be read

Measured on a developer instance: on one item, 35 client scripts came back from the table API with no script field at all. The records are protected, and the API drops the field rather than refusing the row. Elsewhere on the same instance, 22 of 40 did return it.

So "no textual usage found" and "the script was not readable" are kept apart everywhere, and the panel says which one it is. A graph that looks empty because nothing uses the variable and a graph that looks empty because nobody could read the scripts are opposite conclusions.

The flow reader

A flow is read from its own tables, so that the assistant and the alignment check can answer what it does. It is reached through those rather than through a command of its own; /fd opens Flow Designer itself, which is a different thing.

Two traps shaped the way it reads, and both were measured.

Reading only the base table loses the configuration. The step's parameters, its action type, its logic definition and its subflow are not columns on the base table, and ServiceNow drops an unknown field from a field list without saying so, which makes the request look answered. Even the step's display text comes back empty, so not even the name survives.

Reading only the newer subclasses loses every older flow. On a developer instance in September 2026: 1,717 rows in the action instance table against 1,514 in its newer twin, 2,167 against 1,889 for the logic tables, and one real flow returned zero newer rows for its ten steps.

So the base table is queried for the skeleton, which takes every subclass present and future, and both generations of the instance tables are read and merged back together by sys_id.

The parameters column looks opaque and is not: it is gzip inside base64 of plain JSON, verified by decompressing a real one.

The canvas

The flow is drawn on a rebuilt Flow Designer canvas. It is not an interpretation of the design: the geometry was measured off photographs of the real canvas, down to the indent per level, the two levels a branch child takes because the first is spent on the decorator, and the curve on a connector under a branching step.

It is interactive and strictly read-only. Rows expand into their parameters, logic blocks collapse, the data panel opens. Nothing writes and nothing navigates.