Hi! I'm Tim Woodruff. I write most of the articles SN Pro Tips articles, and I’m the author of a few books on ServiceNow development, including Learning ServiceNow, and The ServiceNow Development Handbook. I've put together this quick-start guide to learning ServiceNow development, to give you a quick intro to the things that I personally think are important to know, when beginning a career as a ServiceNow developer.

This article is not meant to actually teach you to be a ServiceNow developer (it’s far too short for that). Instead, it's meant to be something you can reference when you feel like "Okay, what next?" on your journey to becoming an excellent ServiceNow developer. 

Starting a career within a new IT niche can be risky, but the potential rewards can be outstanding.
Maybe you're just starting out your career in IT Service Management development/administration/architecture, or maybe you're a veteran of the industry and you're looking for a change. Either way, in this article, we're going to discuss ServiceNow, ITSM, ITBM, and ITOM as a career-path. We’re going to discuss:

1. Some things you should consider when deciding on your career path

2. Modules and specializations that are in high demand right now

3. Building an ITSM-centric resume, and what to focus on

4. ServiceNow certifications

5. Interview Pro-Tips

6. How to break into the industry without experience

7. Salary negotiation and expectations

ServiceNow admins, developers, and architects are in extraordinary demand, due in large part to the fact that ServiceNow is the fastest growing IT platform in the market, with almost triple the share of its competitors. This, and the ludicrous speed with which ServiceNow has obtained this market-share, has resulted in a strong demand for ServiceNow technical experts.

Whether you're looking to begin your ServiceNow/ITSM, ITBM or ITOM career, or you're already an ITSM veteran just looking for a change, we've partnered with Michael Green, VP of Nelson Frank (one of the few staffing and recruitment firms that I personally trust), to put together some handy interview and resume tips to help you climb the career ladder.

Note: This article is a collaboration. It was not sponsored or paid for in any way.

I often get questions that go something like this:

When a user submits a Catalog Item, I need to be able to do some validation that requires client-server communication (either a GlideAjax script, a GlideRecord query, or a getRefRecord() query). How can I make this happen?

As anyone who’s read my article on requiring attachments in the Service Portal knows, ServiceNow has been (for better or worse) making some changes to how you are supposed to, and able to, do certain things within the platform. What’s relevant to this question, is that ServiceNow does not allow synchronous client-server communication in the portal; which means that your catalog client scripts should not use synchronous versions of GlideAjax, GlideRecord, or getRefRecord().
This is fine, and generally good advice anyway. Synchronous client-server operations lock up the user’s browser, and typically make for a poor user-experience. However - onSubmit Client and Catalog Client Scripts need to run synchronously, because if they don’t return false, the form will submit, reload, and stop any scripts that are currently running (or waiting to run; such as your callback function).

Click “Read more” below, to see the solution!

Scenario: You need to perform a very heavy scripted database operation, on a very large number of times.

To do this all at once, would: (1) slow down your instance, and (2) take longer than the maximum allowable transaction time/sql count/etc. and (3) other bad stuff.
Each operation takes between 10 and 60 seconds because of the additional business logic that needs to run.
You can't optimize the operations, they're simply slow, and there's a lot of them.

Example: You need to reclassify 100,000 CIs from one class to another (a very heavy operation on a large number of records).
How do you handle this?

I’ve run into this scenario a lot, and in every team I’ve been on (which is a fair number), the go-to answer, is to run a scheduled script which does the operation on a batch (some specific number) of records at a certain interval.

But imagine if you have the job run every 10 minutes, and it deletes 20 records per run.
You can imagine a scenario where the instance or scheduled job is particularly slow due to uncontrollable circumstances (such as the volume of integrations hitting the instance at that particular moment, or a discovery run happening simultaneously with the scheduled script). In this case, the job could take some amount of time longer than the average interval between jobs, in which case the jobs would begin to "pile up" and result in a sort of traffic jam that would both be inefficient, and be a massive drain on instance performance.

So the way to do this safely, would be to figure out what is the longest amount of time you could imagine one "batch" taking, and then setting the scheduled job interval to a little bit more than that amount of time multiplied by the number of records per batch. For example, if you do a 20-record batch and each record takes takes between 10 and 60 seconds, you might want to run one batch every 12 or so minutes.

However, if you need to update 100k records at a rate of 1 every 1.2 minutes, that is 120,000 minutes, or 83 days (24 hours per day).

So, for an operation like this, how can we make it the most efficient that it can be, without bogging down our instance?
The solution: Event-driven recursion.

Using a scheduled job with a gap between each job prevents the “pile-up” effect, which is good, and it gives anything else which might be piling up in the queue (such as a discovery run) to have some time to run. But, since each job might take a different amount of time, we have to be overly conservative with our intervals.
However, with event-driven recursion, we can set it up so that each batch triggers the next! This would prevent the pile-up, and send the next batch to the “back of the line” in terms of the scheduling queue. The result would be that the batches would run slower when the instance is busy, but much quicker when the queue is empty, preventing the pile-up effect, and preventing bogging down the instance, both without sacrificing much in terms of the performance of our actual operations (which we’d like to get done before Jules Verne’s round-the-world journey finishes).

Continued in the full article below…

ACLs Vs. Business Rules for security?

Short answer: ACLs.

Longer answer: ACLs, but also sometimes query business rules; but usually for performance reasons more than security.

There are benefits to using Query Business Rules. Namely, performance benefits. This is because query Business Rules fire before ACLs run, which means that not only are you potentially returning fewer records, but you’re also eliminating whatever performance cost may have been associated with the ACLs themselves (which is a non-zero amount, especially if they’re script-heavy). That’s not to say that you should aim to go and replace all of your ACLs with query Business Rules, but there is definitely a case to be made for using both.

On the topic of security, though: one 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 often good! It makes troubleshooting really easy! Personally, I've never had a 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" (using query business rules, which provide no such message) is what anyone trying to troubleshoot missing records could find confusing. 

Click “Read more” below, to see the full article!

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: 

1. Journal Entry [sys_journal_field]

2. Audit [sys_audit]

3. History Set [sys_history_set]

4. 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.

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!

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…

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!