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 anything like me, you're tired of logging in to instances manually, wondering if you've typed your password wrong or if it's expired or been changes, and having to manage dozens of logins - one for each account on each instance owned by each client!
Password managers are fantastic (I use LastPass, myself) but I find that when a password expires or is changed, they always have difficulty telling which client and which instance the login is for -- they treat all logins as accounts for "service-now.com" rather than the sub-domain. And what's worse, they tend to try and auto-fill the "password" fields in user profiles, in the sys_user table! That's no good.
One option for getting around this issue, is to use a custom login link. This makes logging in as easy as clicking a bookmark, and eliminates the extra step of being redirected to the login page before getting to the content you were looking for.
Read on to see the new, free tool released by The SN Guys, that'll help you save time and manage your logins more easily! 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