sysparm_view in ServiceNow and Other URL Parameters Explained

sysparm_view is the ServiceNow URL parameter that picks which form or list view to show, so incident.do?sys_id=<sys_id>&sysparm_view=ess opens an incident in the ess view instead of Default. It belongs to a small family of sysparm_ parameters that control what a page opens, which records a list shows and what values a new record starts with. Learn those, and you can build module links, UI actions and bookmarks that land people exactly where they need to be.

This guide covers the parameters that matter most, how to combine them, and how to build the URLs safely in scripts.

How ServiceNow URLs are put together

Classic UI pages follow a simple pattern:

https://<instance>.service-now.com/<table>.do?<parameters>        form
https://<instance>.service-now.com/<table>_list.do?<parameters>   list

Parameters are joined with &. Values that contain spaces, ^, = or other special characters must be URL-encoded when you build the URL in code.

To open a classic page inside the full navigation frame, wrap it in nav_to.do:

https://<instance>.service-now.com/nav_to.do?uri=incident_list.do

In the Next Experience UI the instance redirects classic links into its own shell, so a plain incident.do link still works. You will see URLs such as /now/nav/ui/classic/params/target/incident.do%3F... in the address bar. The part after target/ is the same classic URL, encoded.

sysparm_view: choose the form or list view

Views are named layouts of the same table. The view name is the Name field on the sys_ui_view record, not its title.

incident.do?sys_id=<sys_id>&sysparm_view=ess
incident_list.do?sysparm_view=mobile

Things to know:

• If sysparm_view is empty or the named view has no layout for that table, you get the Default view.
• View names are matched exactly, so check spelling and case against sys_ui_view.
• A view rule (the sysrule_view table, under System UI > View Rules) can override the view you asked for. When one applies, ServiceNow adds sysparm_view_forced=true to the URL. If a link keeps opening the wrong view, check view rules first.
• The view sticks. When you navigate from a list in one view to a record, the form usually opens in that same view.

sysparm_query: filter a list or prefill a form

sysparm_query takes an encoded query, the same string you get from Copy query on a list filter breadcrumb.

On a list it filters the records:

incident_list.do?sysparm_query=active=true^priority=1^ORDERBYDESCsys_created_on

Sort order goes inside the query with ORDERBY<field> or ORDERBYDESC<field>.

On a new record form it sets starting values:

incident.do?sys_id=-1&sysparm_query=priority=2^short_description=Printer offline

sys_id=-1 means "new record". Each field=value pair becomes a default on the form. Reference fields take a sys_id, not a display value. The values are only defaults, so the user can still change them, and nothing is saved until they submit. Business rules and data policies still apply on save.

If you write encoded queries often, the GlideRecord query performance guide explains how the same operators behave on the server.

Other parameters worth knowing

sysparm_stack is easy to overlook. By default, saving a record sends the user back to the previous page in the navigation stack. Setting sysparm_stack=incident_list.do sends them to that list after saving instead. Setting sysparm_stack=no keeps them on the form.

Build URLs in a client-side UI action

The common real-world use is a button that opens a related new record with fields filled in. Here is a client-side UI action on the Incident form that opens a new child incident. Set Client to true and Onclick to openChildIncident().

function openChildIncident() {
  // Build the encoded query first, then encode it once for the URL.
  var query = [
    'parent_incident=' + g_form.getUniqueValue(),
    'caller_id=' + g_form.getValue('caller_id'),
    'short_description=Follow-up: ' + g_form.getValue('short_description')
  ].join('^');

  var url = 'incident.do?sys_id=-1' +
    '&sysparm_query=' + encodeURIComponent(query) +
    '&sysparm_view=' + encodeURIComponent(g_form.getViewName());

  g_navigation.open(url, '_blank');
}

Nothing is saved until the user submits the new form. One caveat: if a value such as the short description itself contains ^, it breaks the encoded query, because ^ is the separator. Strip or replace it before you join. For more on keeping client code tidy, see the GlideAjax server call example in the script library, which follows the same structure.

Build URLs on the server

Server scripts often need a link for a notification, a log entry or a Virtual Agent reply. Run this in Scripts - Background on a development instance. It only reads data and prints a URL.

var instanceUrl = gs.getProperty('glide.servlet.uri'); // ends with a slash
var query = 'active=true^priority=1^ORDERBYDESCsys_created_on';

var count = new GlideAggregate('incident');
count.addEncodedQuery(query);
count.addAggregate('COUNT');
count.query();
var total = count.next() ? count.getAggregate('COUNT') : 0;

var listUrl = instanceUrl + 'incident_list.do?sysparm_query=' +
  encodeURIComponent(query) + '&sysparm_view=';

gs.info(total + ' active P1 incidents: ' + listUrl);

glide.servlet.uri holds the instance base URL, so the same script works on every instance without hardcoding a hostname. For a single record, current.getLink(true) in a business rule or gr.getLink(true) on any GlideRecord returns a relative form link you can append to that base URL.

Module arguments use the same parameters

A list module (System Definition > Modules, link type List of Records) has Filter and View name fields. These fill in sysparm_query and sysparm_view for you. For a URL module, the Arguments field takes the raw parameter string, for example:

sysparm_query=assigned_to=javascript:gs.getUserID()^active=true&sysparm_view=self_service

javascript:gs.getUserID() inside a filter is evaluated on the server when the list loads, which is how the "Assigned to me" style modules work.

The REST Table API uses the same names

The Table API (/api/now/table/<table>) reuses several of these parameter names, which makes testing a filter in the browser and then calling it from an integration straightforward.

GET /api/now/table/incident?sysparm_query=active=true^priority=1&sysparm_fields=number,short_description&sysparm_limit=10

The outbound REST integration guide covers calling these endpoints from another instance, and the Scripted REST API best practices explain how to read query parameters in your own endpoints.

A quick checklist

• Use the view Name, not its title, in sysparm_view
• If a view will not stick, look for a view rule on the table
• Copy encoded queries from the list breadcrumb instead of writing them by hand
• Use sys_id=-1 plus sysparm_query to prefill new records
• URL-encode the query value once, after joining it with ^
• Pass sys_id values, not display values, for reference fields
• Use glide.servlet.uri instead of hardcoding the instance hostname
• Set sysparm_stack when users should land somewhere specific after saving

URL parameters are also the basis of most admin bookmarklets. The bookmarklets guide has ready-made ones that build on the parameters covered here.