andatory fields are usually pretty simple to work with. ServiceNow provides simple UI policy and client script methods to make fields and variables mandatory. You may have noticed as you have worked with checkbox variables in the service catalog that these methods don’t apply. The reason for this makes perfect sense if you think about it. A checkbox has only two possible values…true or false. When the checkbox variable loads it is already set with a value of false (unchecked). Because of this, there’s never a situation where a checkbox variable wouldn’t satisfy a mandatory check. It will ALWAYS have a value!
What people usually want in these scenarios is to require a user to select a minimum number of options from a certain group of checkbox variables. In these scenarios, this minimum number of items checked really represents the standard for a mandatory check for that group of checkboxes. There’s not a simple way to handle these situations, but I’ve set up some client script solutions that allow you to perform this type of validation if it is needed.
ervice-now provides the ability to automatically move incidents marked as ‘Resolved’ into a ‘Closed’ state after a certain number of days. In my experience I’ve found that this type of resolution/closure workflow is really the best way to configure your incident management setup because it allows end-users the ability to reopen incidents within a certain window (while they’re still marked as ‘Resolved’) but it also ensures that eventually all of the incident tickets move to a ‘Closed’ state where they won’t be reopened so that you can accurately calculate SLAs and reporting metrics.
The key piece to this auto close functionality is the ‘incident autoclose’ business rule on the ‘Incident’ table. It works in conjunction with the property shown here – that sets the number of days after which a resolved incident will be moved to a closed state. The ‘incident autoclose’ script works great but it is based off of a basic date calculation that doesn’t take into account any business hours or holidays. Shown below are some modified versions of the ‘incident autoclose’ script that take into account the default system calendar (in the case of calendar-based autoclose), or your choice of any system schedule set up in your system (in the case of schedule-based autoclose).
orking in Service-now, you’ll find that a lot of scripting tasks come down to identifying which fields changed on a form (client-side) or record (server-side). In this post, I’ll show you some different techniques to identify changed fields in both client-side, and server-side scripts. I’ll also show you a way that you can capture changed fields and values and print them in an email notification…without having to check every potential field in a record.
ere’s a cool tip that I’ve actually wanted to know how to do for a long time. I can’t take credit for it though. I got the idea from a post of a Service-now customer admin, Garrett Griffin. So, thanks to Garrett for the inspiration. I think this is worth sharing with a larger group of users.
I’ve had several questions (one a day or so ago) about how you can return a distinct list of attributes from items in a table in Service-now. This is very simple to do in SQL, but there’s no direct approach to doing this from the Service-now UI. In this post I’ll show you how you can get this type of information both visually, and via script in your Service-now environment.
‘ve written before on SNCGuru about how ‘before query’ business rules can (and should) be used to secure row-level read access to records in Service-now. While this usually works perfectly, there is one issue that I’ve seen come up continually that there hasn’t been a good fix for. Over the past few weeks, I’ve seen several incidents and questions about inactive users disappearing from reference fields in Service-now systems. You may have noticed this yourself when you’ve de-activated users or groups in your system. The culprit in these cases is the ‘user query’ or ‘group query’ business rule.
The recommended (but really not great) solution up until this point is to turn the business rule off and use a reference qualifier on the reference field that you need to see the user in. The reason this solution is a bad one is that there are over 300 user reference and list fields in your system! Not only is that a big pain (and a bad idea) to add that reference qualifier to all of those places, but it also does nothing for the countless places (modules, filters, reports, etc.) that have UI elements that work like reference fields but cannot be filtered with a reference qualifier! This isn’t a new problem, but I’ve come up with a new (and extremely simple) solution.