ServiceNow: Stop or restrict the record from saving when Reference icon is clicked

In ServiceNow, clicking the reference icon on a field — for example, the Configuration Item field on an Asset record — opens the referenced record. If you then navigate back to the Asset record, an auto-save is sometimes triggered even though no field was manually edited on either screen. This creates confusion: a user who only meant to look at a related record ends up quietly modifying the one they came from.

Why this actually happens

The reference icon click isn't the direct cause — the view switch is. Whenever ServiceNow changes the form view (the sysparm_view URL parameter), a submit of the current form is triggered as part of that navigation, regardless of whether any field was touched. That submit is what shows up as an unexpected "save," and it's also what updates the Updated / Updated By fields even though nothing looks different on the form.

Because that submit is already underway by the time it happens, you can't stop it with current.autoSysFields(false) in a business rule — that call needs to run before the update is initiated, not during it, so it's too late by the time the reference-icon navigation kicks off its submit.

Step 1: Find out what's actually triggering the update

If a client script is silently marking the record as modified — for example, an onLoad script that sets a field like u_view every time the form loads — that's usually the real culprit, not the reference icon itself. Moving that logic from a client script into a business rule avoids marking the form dirty in the first place.

To identify the current view name server-side (if you need that value for existing logic), a before update business rule can use:

var transaction = GlideTransaction.get();
var viewName = transaction.getRequestParameter("sysparm_view");

Once you've moved the logic and deactivated the client script, test again. If the auto-save no longer triggers, that was the cause. If it still happens, some other field is changing behind the scenes — which is common enough that it's worth a dedicated way to catch it.

Step 2: Find out which field is changing, if it isn't obvious

Add this to a before update business rule to log exactly which fields are considered "changed" at the point of the update:

var actionName = action.getActionName();
gs.addInfoMessage('Action performed: ' + actionName);
if (actionName == 'sysverb_check_save') {
    var gru = GlideScriptRecordUtil.get(current);
    var changedFields = gru.getChangedFields();
    gs.addInfoMessage('Fields changed: ' + changedFields.toString());
}

GlideScriptRecordUtil has been a standard global script include for a long time now, so the older fallback pattern of checking typeof GlideScriptRecordUtil != 'undefined' and dropping to Packages.com.glide.script.GlideRecordUtil.get(current) isn't necessary on current instances — that direct Java Packages.* access is an unsupported, global-scope-only technique, and it won't run at all in a scoped application. Stick with GlideScriptRecordUtil.get(current) directly.

A common real-world cause this surfaces: a currency field (like Cost on Asset) that's blank by default but gets initialized to $0.00 the moment the form loads, which counts as a modification. Fixing the field's default value — both going forward at the dictionary level and retroactively on existing blank records — usually resolves it.

Step 3: If the field logic truly can't be moved

If you can't relocate the responsible logic to a business rule, you can't cleanly prevent the save. As a fallback, you can at least warn the user that a change is about to be saved by checking g_form.modified in an onSubmit script when action.getActionName() == 'sysverb_check_save', and returning false with an explanatory message if appropriate. Be aware this cancels the entire action — the user won't be able to navigate to the referenced record either, since the same click is what triggers both the submit and the navigation.

Step 4: System property options — and why they're broader than they sound

Two properties get mentioned often for this scenario. Both are instance-wide, so treat them as a last resort rather than a first move:

• glide.ui.reference.readonly.clickthrough controls whether the preview/reference icon appears on read-only reference fields specifically — by default, a read-only reference field hides the icon; this property can turn it back on globally. It does not control whether the icon appears on ordinary editable reference fields, so it isn't a general-purpose "hide the reference icon everywhere" switch. If your goal is to suppress or enable click-through on a specific field rather than instance-wide, the readonly_clickthrough dictionary attribute on that field is the better-scoped alternative — same effect, without touching every other read-only reference field in the instance.

• glide.ui.clickthrough.popup changes reference-icon clicks to open the referenced record in a popup/new window instead of navigating in place. This does sidestep the view-switch-triggers-submit behavior described above, but note the popup view doesn't display related lists the way normal navigation does — worth testing before rolling it out broadly.

One more thing worth checking: which UI you're actually on

This entire behavior is tied to classic UI (UI16) form navigation and its view-switching mechanics. If your users are working in Agent Workspace or another Next Experience/UI Builder-based workspace, reference field previews typically open in a side panel rather than triggering a full view navigation — so this specific failure mode may simply not apply there. If you're troubleshooting this on a workspace and still seeing unexpected saves, the cause is more likely something else entirely, and it's worth confirming which UI the affected users are actually in before spending time on the fixes above.