There are benefits to using Query Business Rules. Namely, performance benefits.
These benefits are typically very minimal, especially as compared with the down-side versus using ACLs to control access to certain records.
The main reason that I see people using query Business Rules is because they want to get rid of that “n records removed due to security constraints” message which shows up when ACLs block access to records in a list view. However - that message is good. It makes troubleshooting really easy. Personally, I've never had a single user complain about this or be confused by it, and it's really simple to explain if they do. The lack of such a message, when records are removed by "security" (query business rules) is what anyone trying to troubleshoot missing records would find confusing.
There are a lot of reasons not to go replacing your ACLs with query business rules, and in this article I go into some detail as well as explain some extremely odd behavior that queries have in ServiceNow (due to the behavior of SQL). Click below to read on! Read More
After being asked how to remove information from, or delete, a journal entry three times in as many days, I finally decided to get off my butt, and write this tool. Then I realized that it's difficult to code standing up, so I sat down back on my butt, and got to work.
If you've ever tried to modify or delete a journal entry, you probably already know what an ordeal it can be, and you've likely sunk hours into the attempt, if not thrown your hands up in frustration altogether! There are at least four distinct tables involved in modifying/redacting or deleting a journal entry, each with a unique schema, some dependent on others, and some stand-alone:
Journal Entry [sys_journal_field]
History Set [sys_history_set]
History line [sys_history_line]
"Why the hell is this so complicated?" would not be an unreasonable question to ask, but each of these tables actually does serve a unique and valuable purpose. The difficult part (once you've identified all of the tables a journal entry's data might reside in), is identifying how they all work together. Then you have to actually locate the record in each table that corresponds to the specific journal entry you want to redact, and modify it in some way (which may be different depending on what you're trying to do, and what table you're interacting with.
Or - you could simply grab the tool I've just written, and use that instead! Click below to read more. Read More
If you typically use a single account for your "admin" duties, as well as for creating and updating tasks, approving changes, and so on, it would be easy to accidentally utilize your "admin override" functionality without even knowing it. There is no notification or other indicator when you're only able to see some option because you're an admin and thus overriding an ACL! You might end up accidentally making some change that you shouldn't be able to make, such as approving or changing the state of a change record that would otherwise be locked down.
To avoid this, some companies require that admins have two separate accounts: one "normal" account with their group's non-admin roles, and a separate "admin" account that they must log into locally on the instance. This is an okay solution, but requires a lot of flipping back-and-forth, makes it difficult to update tickets as you're working on stuff, and often leads to people just using their admin account for everything because it's more convenient. There is however, a better way! To avoid accidentally using your "admin powers" when you don't mean to, you can simply set the admin role to an elevated privilege!
Click “Read more” to find out how! Read More
If your instance has been around for a while, you've probably built up a few tables that are quite extensive. The good news is - there are steps that you can take to both mitigate, and even preemptively prevent this issue.
"Table Rotations Groups" are a little-known feature that allows you to split very large tables into manageable chunks. There are two types of table rotation groups: Rotation, and Extension. What we're going to use today, is an extension type. This means that every so often, the table you're rotating will be extended, and all new data will go into the new extended table.
There are specific use-cases for each table rotation group type. Extension is best for when a table is queried by the sys_created_on field often, but you need to retain all historical data. Rotation on the other hand, sets up a specified number of tables to rotate through using, for a specified period of time each - but once all tables have been used for the specified period of time, it goes back to the first table and overwrites it. This means that data in these tables is not permanent. There is an OOB "rotation"-type extension on the syslog table, for example.
The benefits of this may not be obvious, but consider the following scenario… Read More
If you're a ServiceNow Express customer, then you probably already know that ServiceNow is forcing everyone on the Express edition of the "Now platform" to upgrade to the Enterprise edition. While you might think that after an upgrade, you'll have a typical ServiceNow Enterprise instance, that is not the case.
The Enterprise edition of ServiceNow is far more powerful than Express, but there are some significant differences between the two platform editions, and much of the added functionality of the Enterprise edition is not enabled by default after an upgrade. You'll also find that some things in your post-upgrade instance have retained the names of their "Express" counterparts in the Application Navigator, for example; which can make it difficult to navigate around, or use the platform documentation.
In this article, I'll briefly explore some of the differences you can expect, some of the features you can expect to be missing, and how you can enable that functionality post-upgrade. Read More
You can categorize the ServiceNow dev community into two camps: Those who love the idea of "application scope" and how it's been implemented, and those who think that scoped apps in ServiceNow are a bit broken.
As you may have guessed from the title of this post, I belong to the second camp, but hold on, don't go for your pitchforks just yet. I come with a peace offering: a few humble suggestions. Not to do away with scoped apps, but suggestions which I think might make scoped apps a little bit easier on all of us.
As the title of this post says: If a genie popped into my life (presumably by way of a magical lamp) and gave me three wishes, I would use them all to - in my opinion - "fix" the issues with scope in ServiceNow. That's my dumb way of saying that I think the implementation of scope in ServiceNow isn't quite as great as it could be, and is the source of some frustration for myself and my developers; and suggesting some alternatives which might make sense to consider.
Hey, at least I didn't make it "Top 3 ways I'd change scope in ServiceNow - You won't believe #2!" Read More
When building or modifying a Catalog Item in ServiceNow, the Try it button is fantastic for allowing you to quickly and easily see what the changes you've made look like in your development environment. This is a crucial tool for testing!
However, as many of you will no doubt be aware, there are significant differences between the "classic" UI, and the Service Portal UI. Certain field types look and behave differently. Some even have different APIs for interacting with them in the Service Portal!
For this reason, it's almost always important to be able to quickly and easily view your catalog items in the Service Portal as you're building them, as well as in the classic view. Unfortunately, there is for some reason no out-of-box way to do this!
To remedy this, our Service Portal developer (Kim) built a custom "Try in Portal" UI Action, which does just what you might expect - it allows you to preview your catalog item in the Service Portal.
Read on to see how this works! Read More
Unless you're somehow still rocking UI15 and do most of your development on a Commodore 64, there's a good chance that by now you're at least vaguely familiar with ServiceNow's new(-ish) Angularized end-user front-end feature: the Service Portal.
If you've tried to implement your Service catalog in the Service Portal, there's also a good chance that you've wept openly over your keyboard, trying to find an effective and non-hackey way to replicate functionality that was readily available using out-of-box APIs in the old Jelly-based CMS and catalog form. Stuff you'd think would be really basic, especially two full major releases later, it just not possible in the Service Portal. g_form APIs like getControl() and getElement() (and gel()) don't exist in Service Portal. Neither does any synchronous GlideRecord query or GlideAjax call, meaning that if you want to check something on the server in an onSubmit() script, you're out of luck.
One of the biggest annoyances resulting from this, is that there is no good way to check if a catalog item has attachments as the user submits the form. This means that you cannot make attachments required on a specific catalog item.
Oh sure, there are sort of ways to do it, such as modifying the catalog item widget just for that catalog item, so that the client controller and server script work together to check for attachments. Or you could embed the whole CMS or ITIL UI catalog item form in an iframe. Unfortunately, both of those have major downsides.
I've made this solution, in order to restore some basic functionality, with a mind toward the specific problem of checking for attachments in the Service Portal.
Here is a basic feature-list of the below functionality:
- Require attachments on submission, using sp_form.getAttachments()
- Require attachments of a specific type
- Require a specific number of attachments
- Require a specific number of attachments of various types
- Access DOM element of variable field input box and div element, using sp_form.getElement() and sp_form.getControl()
- Access variable names, sys_ids, and question text, using sp_form.variables or sp_form.getVariables().
- Iterate over each variable on the page, or otherwise retrieve variable sys_IDs, names, and question text without having prior knowledge of each within your catalog client script.
Click below to read on!
Dealing with Time Zones in ServiceNow can be a real nightmare. The only documented way to set the time-zone of a GlideDateTime object, is the setTZ() method. Unfortunately, this method requires a "TimeZone" object be passed in, in order to set the time-zone.
At least, you were. Sufficiently annoyed by this problem, I finally decided to write a Script Include to handle this for me, and now that I've been using (and testing) it for a while now, I'm comfortable publishing it for general consumption.
Click below to read on, and get a copy for your own instance! Read More
ServiceNow has effectively prevented its customers from utilizing any form of DOM manipulation in the service portal. For those who were brave enough to invest heavily in the Service Portal early on, this has caused major issues.
Nearly every ServiceNow customer with an even moderately utilized Service Catalog, has some Catalog Client Scripts which make use of things like g_form.getElement(). Here are just a few things we've run into, that we're not able to do in Service Portal without MAJOR custom hacks:
- Use the document object to retrieve URI parameters in order to parse them for a client script
- Adds event listeners to input fields on load in order to monitor for events other than "change" which requires entering the field, modifying some data, then tabbing out of the field again.
- Parse URI parameters to do any kind of auto-population or other processing based on them, by using document.URL.parseQuery() (the solution recommended by ServiceNow).
- Toggle form containers
- Get information from fields in other widgets,
- Redirect pages
- Show/hide/change a variable label, variable set, or container dynamically
Click below, to keep reading and learn how to re-enable all of this functionality in your Catalog Client Scripts on the Service Portal. Read More
I don't know about you guys, but having worked with ServiceNow since the pre-Fuji days, I can hardly believe how far the platform has come in just a few short years.
If you've been following SN Pro Tips for a while, you may have seen our articles on Geneva and Helsinki. In that same spirit, today we're bringing you a break-down of what's new in ServiceNow's Jakarta release, and all the main points you'll need to know and keep an eye out for, as an Admin or developer.
This has been another really significant update to ServiceNow, so we can't cover every little detail, but if we missed something that you think is important, please leave a comment and let us know your favorite new feature!
Click below to read on, and learn what's new in ServiceNow Jakarta! Read More
If you've ever searched from the list view of a given table, you may have seen the "for text" option next to the search box in the list header.
This search box can be configured to directly search in any field which is displayed in the list view, but you can accomplish that just by clicking the "magnifying glass" icon to the left of the column headers.
You might notice though, that this text search isn't.... very... good. For example, if you search for multiple words like "blackberry configuration", the search assumes that you want all of the words in the search to be included in any of the results returned, so results like "blackberry setup" would not be shown.
Let's explore why, and see if there might be a better way to do this kind of text search in our scripts.
In this article, we're going to learn about the differences between 123TEXTQUERY321, IR_AND_QUERY, IR_OR_QUERY, and - IR_AND_OR_QUERY, as well as how to use them in scripts! Read More