One of the biggest selling points of the ServiceNow Platform was and (I hope) still is, is the fact that you can customise it so much that it has grown into an application development platform. Since the early days, there has been an explosion in the number of applications that can be enabled from a plugin or downloaded from the Store. But, boy, is it hard to keep up. That's not a bad thing itself, but what can be considered bad is that sometimes we may revert to trying to build a solution without checking if one already exists. And I don't blame you. Some are just plain addicted to coding, that you end up threatening to get the handcuffs out.
Image courtesy of kazan.vperemen.com
So, what do I have to say about this? Well, if you are going to build a solution, try to resist coding. Think about it. Sometimes you code the next greatest Script Include and it just doesn't work despite all the awesome debugging you're trying to do. Then we get another pair of eyes and immediately (can take a bit longer) they find a typo. And let's say you pose that question in the Community or in an Incident, how many times has someone suggesting an alternative route best suited to your needs. In either case, there's that feeling. Oh, you know that face-palm feeling. No-one expresses it better than our dear Homer Simpson
So let's see what functionality is on offer to where coding may not be required
Field Behaviour
This is a classic one and our ServiceNow veterans can tell you all about it. In the past I've seen some muddled code in a Client Script to play around with the fields with respect to their visibility, read-only or making them mandatory, based on other fields on the form. To change the visibility, the g_form API offers two methods setVisible and setDisplay where the results are functionally different but are sometimes used interchangeably in those naughty (yes, naughty) scripts.
I'm actually using the visibility issue to drive the rationale for what I'm about to suggest. If all you're doing are Form checks to drive the behaviour of a form field, then just stick with UI Policies. With these, you don't need to spend time in thinking how to code a condition and then how to change the behaviour of the field. The platform does all the hard work for you. What's also cool about them is that you can toggle a field to reverse the logic if the condition evaluated otherwise. See? No coding. Okay, well, there is an option to throw in a script to do a bit more work once the condition is evaluated. But then you need to evaluate whether the UI Policy can do it or is limited. To get this you have to go into the Advanced View of the form, which suggests you really know what you're doing. If you don't, then be prepared for when you raise that Incident.
Get the Advanced view by clicking this related link.
Now, this screenshot serves a secondary purpose. See that link that says Convert this to Data Policy? I suggest you click that. This would on the UI Policy form if you are playing around with making a field read-only, or mandatory or vice-versa. Why choose this route? Okay, let me explain with a scenario you may be familiar with:
Let's say there's a Javascript error being thrown from somewhere on the form, we know that the browser can just stop processing any subsequent Javascript because of this error. Imagine you have a UI Policy making a field mandatory and this error occurs before this UI Policy's code is evaluated. What would happen? That UI Policy will not make that field mandatory and you can end up with records that does not have that field filled in.
But then. What about integrations? How can we ensure that the field is filled in or prevent the record being created when the field is not being populated? If you say Access Control Rule, I won't get angry (no promises), but think about it. You're going to end up with more than one control for one field. That's a bit overkill, no?
This is where creating a Data Policy is the answer. It can be extended to the UI (where the equivalent UI Policy is created) and can influence Import Sets and SOAP. All the "protective mechanisms" are done on the server.
Access Control Rules
Since I mentioned Access Control Rules, I have to talk about it. But why would that be on this list? When I was in Customer Support, I witnessed a large amount of ACL related issues. Most of the rules we looked at had scripts. I guess some saw it as a consolidation effort. However, since the Fuji release, there was a redesign of the form where the Script field is enabled by the Advanced checkbox.
Now, this sets a precedent. You really have to think about that requirement, not the technical part, but the requirement itself. Are you really certain that it cannot be achieved using the Roles and Conditions, or implementing more than one control? Sure there's going to be the need to script the solution. I don't doubt that. But I'm hopeful that this option makes us rethink our decision. So, if you're going to do it, try to keep the code clean and easy to read, and make use of Script Includes. Modularising the code into Script Includes will (hopefully) encourage re-use.
Business Rules
I guess this is going to be a very sensitive area where some will have their own (strong) opinions about how and when Business Rules are used. Though, it is probably agreeable to state that if you are going to code, try to do it server-side, and Business Rules are the common target for this approach. As an example, GlideAjax is commonly advertised as the solution to most Client Scripts. Is it really? Yes, it's asynchronous so the browser does not get locked up waiting for a response. But, if you have a lot of GlideAjax or other asynchronous lookups running when the Form is loaded, are you doing the platform performance a favour?
One of the most undersold and underused variables is g_scratchpad where you can grab anything from the server-side (field values from other tables, calculations based on other fields) and shuffle it across to your Client Script. I would strongly suggest you consider rolling up some of those on load async calls into one call and store the results in the g_scratchpad variables. The other benefit to this is, being on the server-side, you can take advantage of the Glide APIs that are available as well as your Script Includes.
A good example of using this is determining whether the current record has any attachments:
g_scratchpad.hasAttachments = current.hasAttachments();
So now then can use this in a Client Script like so:
if (g_scratchpad.hasAttachments) {
// let's make magic happen
}
Since the current topic is Business Rules and I'm trying to encourage minimal coding, you may (or not) have noticed an update to the Business Rule form in Eureka.
Before and After (From Dublin to Eureka)
We could play spot the difference, but what I really wanted to point out is that the Script field is no longer there (Yes, the Where field is missing. We'll get to that). As with the common pitfall of scripting, there's gonna be typos. So we have a way to build conditions (in the above screenshot) and the Actions section/tab (below) for the record updates. Let's have a look:
See that? A condition builder is presented so we can easily update fields. No more do you have to play around with currrent, urrent, curent... you get the idea . Plus, we have the options to show a message (instead of coding gs.addInfoMessage) and to cancel the database action (gr.setAbortAction(true)).
If you're gonna code and there's no stopping you, just as with creating a new Access Control Rule, tick the Advanced checkbox to get the Conditions and Script field. Plus, you get the When, Delete, Query and Order fields. Then in Fuji, the form has another improvement, encapsulating the scripts so you don't have to
function onBefore(current, previous) {
//This function will be automatically called when this rule is processed.
}
Then there's the usual advice... use Script Includes.
Summary
I could go on for a long time but that's it for now. However, it is very clear that the platform is constantly evolving to minimise on the need for coding. But if it's required, there's a lot more to consider with regards to what is good or bad practice, and there's plenty of useful blogs out there in the Community. I just wanted to give a starting point for you to consider when developing on the platform.
Plus there's a very cool K17 Lab to create an app from scratch that's worth going through Building a No Code App from Scratch.
