ServiceNow adds a ton of great functionality to each new product release. Often times, the most helpful and useful features (at least to a long-time user of the system) are enhancements to simplify or improve on existing functionality. Unfortunately, these are often some of the most under-appreciated and end up getting lost in the marketing hype of all of the brand new capabilities that you may or may not use. One such example that recently arrived to ServiceNow is ‘Dynamic filters’. In this post, I’ll share what dynamic filters are, and show how you can extend and leverage this capability to improve your own ServiceNow system.
Record producers are a great piece of ServiceNow functionality that allows for the creation of records in any table via the standard Service Catalog interface. This capability has been around for quite a while and odds are that you’re already using it in your system to allow end-users to create new incidents…among other things.
Over the years I’ve worked with ServiceNow, I’ve seen several requests to be able to report on or identify the record producer used to create a particular record. This would allow for easier identification of the entry point for record producer transactions. Unfortunately, ServiceNow doesn’t give us a simple way of accomplishing this. Even though there is a record producer ‘Script’ field and a ‘producer’ script object to work with, nothing is built to be able to dynamically identify the record producer used. This means that you’re stuck hard-coding values in a script or adding unnecessary variables to your record producer forms for every single record producer in your system. Read on for a fairly simple solution to this problem!
co-worker asked me for some help yesterday fulfilling an interesting requirement. He needed to set up a configuration item reference field or catalog variable that would display a calendar macro that, when clicked, would open a popup window containing a change calendar report for that configuration item. I figured this idea might be of use to others so I’m posting it here!
Reporting in Service-now.com is usually very simple. One challenge I’ve seen before with the Service-now reporting interface is that it displays a lot of tables to most users as tables they can report on. The list of reportable tables is controlled by system security ACLs. If a user can read a table in the system they can also report on that table. There are many cases where users need to be able to read from a table in order for the system to work correctly for them, but you may not want users running reports on that table just because they see it as an option in the reporting interface. I’ve created the Restrict Report Tables update set as a solution to this problem. It gives Service-now report administrators granular control over which tables in the system show up as selectable options in the report interface.
just figured out a cool little reporting feature today that might end up helping somebody. On the reports homepage (‘report_home.do’) in Service-now.com, users have the ability to type filter text to restrict the types of reports that they see. So, if I wanted to see just those reports on the ‘Change request’ table, I could simply type ‘change request’ for my filter text as shown below…
Now for the cool part…