Avoid these types of things when working in ServiceNow

From time to time I get thinking about what I really avoid in this system. Below are my notes.

Controlling variables state with fields

For example, setting the field as mandatory or read-only on item_option_new.

  • Problem with this is that this is yet another place to control this. You have the following already;
  • Variable Settings
  • Before Business Rule
  • Catalog UI Policy
  • Client Client Script

Controlling fields state with fields

For example, setting the field as mandatory or read-only on sys_dictionary.

  • Problem with this is that this is yet another place to control this. You have the following already;
  • Field Settings
  • Data Policy (best as it controls the field in both the backend and the front end w/a checkbox)
  • ACL ()
  • Before Business Rule
  • UI Policy
  • Client Script

“Reverse if false” on UI Policies is sketchy!

If you have multiple UI policies condition that is based on the value of a select variable you will likely have problems as they will evaluate in weird ways.

Instead uncheck reverse if false, and make those UI Policies work well when the condition is met and abandon hope on the “Revese if false” bit.

Thanks Mav and Monicask

Using stage fields for any logic

I’ve found that this field is not as clearly set as you might think. So I’ve started to use this only for the display of the stage to the user and not for any other purpose.

Putting things in workflow

  • Custom workflow activities (rest activity)
  • Notification activity > This is another place to configure emails but these emails are not subscribable, not easy to re-generate, and difficult to edit as you need to check out your workflow.
  • Switch activity > I try to minimize my need of this by keeping workflow logic concise. If that’s not possible, you can always do something like this > Just had an issue where a workflow started with a begin then switch, and the switch did not build the context records properly so the workflow just hung. Just another reason to avoid Switches.

Execution Plans

These were used prior to Workflows. At the time I used them they were loaded with a bunch of issues. Workflow has a lot more flexibility.

Global Business rules

These are loaded on every. single. record. They are bad, you should include the code you want to run not expect it to be available everywhere.

Script includes written like Global Business rules

Here this post goes over the following patterns;

  • Class Pattern
  • Function Pattern
  • Namespace Pattern
  • Global Include Pattern (really just multiple function patterns in one record)
  • Module Pattern

Of these, I think the Function and Global Include Patterns should be avoided. The reason being is that they are really no better then a global Business Rule.

Form Designer

This gives generic column names to fields. Also this doesn’t name sections right, so some functions like g_form.setSectionDisplay('') fails to work.

Catalog Item Designer

Issues I’ve been told of;

  • No logic available. So instead of an item for 2 types of things, you’ll need to make 2 different items.
  • Variables aren’t created on item_option_new, which brings up a slew of other problems.
  • Variables can’t have reference qualifiers.
  • Every change to the item, makes a new version of the item with a new sys_id so old links now no longer work.

Storing credientials in code

Always store these in system properties as passwords or as credential records. If you store them in code the are in clear text and that’s never a good idea. At least if you put them in a credential record or a system property additional steps have to occur to decrypt the value.

Outbound Rest Records (go record-less)

This is just extra stuff to configure in my opinion. More places to check for errors.

Dom Manipulation

These types of changes generally break on any GUI update from SN. They are also unsupported on Service portal and Mobile.

Avoid using $

It’s come up often enough that when folks see $ in UI Scripts, UI Pages, and other parts of ServiceNow, they thing jQuery because that became really popular and started to use that, however, ServiceNow assigned $ to prototypeJS, and not jQuery, as such, I’d just spell out jQuery() instead to be clear about what you are expecting to use.

Edit this page

Avatar
Jace Benson
ServiceNow Developer

ServiceNow is my day job, JAMStack is my passion.