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