Jun 13, 20215 min read

Quebec Features - The best of ServiceNow so far

For example, a filter can be added to the task table to find out incidents where I am the caller, or change requests where I am the requester.

The above query on the cmdb_ci table can be re-written using a simple reference qualifier on quebec.
However, this can be done pre-quebec, using the ref_ prefix on the fields. To elaborate, let's take a simple filter of finding all incidents and CRs raised by Abel using this filter:

ref_incident.caller_id=62826bf03710200044e0bfc8bcbe5df1^ORref_change_request.requested_by=62826bf03710200044e0bfc8bcbe5df1

This query can be re-built on pre-quebec versions and it would still work, thanks to the ref_ attribute.

On list view and in reports, we now have a natural language search capability which allows users to write search queries as string. Using the right keywords, this search feature will turn into a powerful tool.

The features are so vast that it allows us to display results the way we want - like a pie, list. etc, and even use some of the keywords like reassignment count, priority, assignment group name, my team, etc.

The Natural language search also does auto-complete, auto-correct typos, and gives you a list of your recent searches.

This is a cool feature that has been added to reporting, where creators of the report now have the flexibility to decide the format of the results for values dealing with numbers.
For example, if a score report is used, rather than displaying a result as 1000, 1000000 it can be formatted to 1k, 1M, etc.

Ever wondered if there was a magical field to manipulate and operate on data from a table the way we want it to? It's finally here.
Function fields allow admins/privileged users to store data on them based on operations performed using other fields in the table.
This option seems to be present only in the report UI:

The logic for configuring the function field is simple - You give the function field a name, set its return type (it's fair to call it "field type"), select what function operation you want to perform, and finally select the fields which will act as the parameters for the function:

For instance, function fields 'Custom Short Description' & 'Time to Resolution' were created to store values that are not available in the incident table, but using data from the table.
The magic of function fields don't stop here, you can later access these fields if you have access to data on the table - from lists, forms, and even write ACLs on them!

These fields are created with the prefix 'u_rpt_' on the database.
Also, these fields can be de-activated from the report config and later activated again (basically works on the active check).

This is a GAME-CHANGER when it comes to ServiceNow's upgrade capabilities.
The Upgrade center application allows us to do a 'preview' of the next version of SN before actually engaging in the process.
This preview can be done specifically to patch/hotfix level!

Doing a preview will give us the list of changes that were involved in the upgrade, Predicted skips: list of possible skipped items, and Predicted skips reviewed: the list of items that are reviewed so far.

The coolness doesn't stop there, you can even have access to the list of problems fixed by SN in that upgrade version, customized release notes (if you are skipping SN versions during upgrade), and access to the known error portal.

You also get a beautiful UI of the predicted skipped objects by priority and monitor your progress on the skipped object review.
A ton of other features show up after you have scheduled and completed an upgrade. To name a few, the upgrade monitor will show reports on the skipped objects, a separate report for code that is changed, a list of plugins that are newly introduced, and many more.
VTB for skips is present pre-quebec, which is also a powerful feature to manage work.

Uncertain times dealing with breakpoints on the script debugger are gone now :) - Script tracer allows you to track all scripts that run while you are performing a UI transaction.

This feature allows us to trace all server scripts that run, along with a search feature!
You can choose from the categorized data from a table and the type of script run.

To this never-ending list of features, add 'Instance scan' as one of the biggest head-turners.

You can run a complete or a scheduled scan on your instance, using the list of configured checks that are present or create more checks on your own.
Checks: The way how this works is, a check can be created under one of the following use-cases:

Once a new check record is opened, you can choose the purpose of the check from the following categories:

A bunch of other important information can be configured to show when the scan finds records matching the check, like priority, a SN documentation link, possible resolution information, etc.

Condition builder or advanced script condition can be used to configure which records need to be chosen for this check and what is the actual check performed on.
Looking at OOB checks can give you an idea of how the script field is utilized for this. The only takeaway i could get is, almost all scripts have this towards the end of the script:

finding.setCurrentSource(grHRR);
finding.increment();

Suites: allow us to Create a specialized bunch of checks (can't create checks here, you can pull them from the slushbucket)
Suites can have parent and child suites, and we can always schedule them as necessary.
Table Cleanup: Also called as auto-flush, gives us this amazing privilege of cleaning up records on tables, based on the age in seconds.
For example, referring to the sys_updated_on field, you can set a value to the 'Age in seconds', so that records living beyond that will be automatically deleted. Supports cascaded deletions too.
Results: Has records based on the scan run.
Findings: Has records based on the check records against all scans run.

ServiceNow has done a solid on this one. You might just find bullet-points for this topic, but all of them are ground-breaking:
Apart from having a 'mandatory' checkbox for variable definition, we now have 'read-only' setting for all variables and 'Selection required' for checkbox types.
You can configure a variable as 'Hidden' so that it doesnt show on the request form. This will save plenty of time from writing UI policies to hide variables that are mostly used for calculations or only after the request is submitted, serving no purpose to the requestor on the request form.
Variable choices can now be marked 'inactive'.
Just like data lookup definitions, we now have catalog lookup definitions (under the same module, shows as an interceptor while creating one). This lookup can be configured based on catalog item or variable set.

Recent Posts