ServiceNow features I avoid, and you should too

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

Controlling variables state with fields

For example, setting the field as mandatory or readonly on

Controlling fields state with fields

For example, setting the field as mandatory or readonly on

"Reverse if false" on UI Policies is sketchy!

If you have UI policies condition that is based on the value of a select variable you will 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

Execution Plans

These were used before 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;

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;

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 extra records to configure. 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 popular and started to use that, 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.