Core Configurations

1. Scripting In SerivceNow

In service now, all the scripting can be divided into two types: server-side scripting and client-side scripting. Basically, the difference between these two is the location where this particular script is getting executed. If the script is getting executed on the client side, it is called client-side scripting. If the script is executed on the server, it is referred to as server-side scripting. What is a client and what is a server? Let's try to understand that in this particular session. First, what exactly is a client? The client is nothing. But let's say, for example, if a user orit could be an end user, ITL, or admin. Whenever we are accessing our instance from the web browser, we're actually sending certain requests to the server. Once the server gets the request, it will respond back. So the client is nothing but our web browsers. The server is the place where all the data regarding our instance is stored. It could be problem tickets, change tickets, or incidents, for example. All the data in our instance is stored. All the data is stored in the service, no servers. Nothing is actually stored in our web browsers. On our particular desktops or laptops, everything is stored on servers.

Whenever we open the application from our browser, it actually sends a query to the server. It is nothing but a request. And then the server will run certain scripts and it will respond back by providing the data which the client has requested. This is the basic process. What happens whenever we reopen a particular record? It could be instant record or any record, or even if you are opening any list of records. Even then,basically what happens is the client sends a request to the server that I want so and so data, and the server responds back giving the data. Let's try to understand this in our service instance. In our Service Now instance, if we're accessing any page, let's say I'm searching for the incidents here. What exactly happens? Is it actually querying the server? Please provide me with all these details: all the incident record details. So that is what we get over here. And at the bottom, if you click on this, it will show the data related to the querying time. Let's try to understand different timings. Here, the first one is network. So the network is the one. Basically, the client is sending a request and the server is responding, responding back with data.

What is the medium? It is the internet. The network. Currently, my network is taking half a second to send and receive the data. And the server, the service no server, takes one and a half seconds to complete its scripting and provide the data. So this is in milliseconds. If you are converting it to seconds, it will be one and a half seconds, and the browser will take around 10 seconds to load the data from the service. This is how we can define exactly what the time is being spent on. Now, if, as I said, if the script is running on the client side or in my browser, then that is called client-side scripting. If the scripts are getting executed on the server side, then they are server side scripting. Different configuration things run in different places, like client scripts run on the client side. The client-side business rules script includes UI actions. These all run on the server side. UI actions can also be run on the client side. Let's talk about all these things in our next sessions.

2. UI Policies

In ServiceNow We have a thing called configuration called the UI policies. With the UI policies, we are going to do three things: mandate, visibility, or read only. So we are going to do three things, or we are going to set three attributes to the fields with the UI policies. What are those attributes? Making a field mandatory, or making a field editable, or making a field visible. Let's go ahead and, first of all,let's look into our vulnerability records. I'm going to one of the records now. We can see certain fields in this particular vulnerability management record. First, you can see I created and updated all these fields. The situation is like the reason we use all these four fields. It has been updated. Basically, the system automatically populates these whenever a report is updated. The recent updated time will be added over here and the person who has updated their name will be shown over this particular speed. This is something done by the service. Now, by the way, I mean out of the box. So users should not be able to edit these fields, right? So the requirement is to make the updated field read only. And also, whenever we are going to submit a vulnerability record, we must make sure that the short description field is mandated. Which means if you are submitting a record or if you are saving any record in particular, the short description should be filled in.

If it is not filled, it shouldn't be allowed. We should not allow the user to save the record. And let's say we want this price field hidden. Okay, so how we can do this is through UI Policies. Just type UI Policies and under the system UI you'll be able to see the UI policies. This is again a table. UI policies are a table. In this table, we are going to create a record in this table.Click on new. There are certain things which you need to understand on this form. Basically, I would say for now,let's only consider three things. On which particular table should this UI policy run? For now, I'm going to select one RBTmanagement table because we want those attributes to be either field mandated or field visible. So that has to be done on this table, right? So I'm going to select this table. Now, a short description is something for our reference. If we see this short description, it should actually let us recall or inform us what exactly this UI policy does and when this UI policy should run. If this condition is met, then the UI Policy will be running. Let's say the short description, let's keep it as a basic UI policy. Now we need to find our UI Policy. So this is the one that we have created.

Once the UI policy is created, we should have the UI policy actions created. If we see the related list, it is right now blank. Let's set a new record. Now, here, this is actually the place where we are going to select the fields and select the set, the attributes. The first field is as discussed earlier. We need to make the updated field as read only.So these are the attributes that make it feel mandatory, visible, or read only. So I'm making the updated field read only true. In the same way, again, I'm creating a new UI Policy. This will be in the short description field. The attribute is mandatory and true. Then finally, we have one more field called Price Field, which should be visible if I'm selecting the field, thePrice field, and visible false. Whatever fields we see over here,actually, those are the fields that created this table, this vulnerability table. So that's it. Now all three UI Policy actions are ready. Let's see how this particular UI policy behaves. Let's go to the form and see how it will work. Instead of going through the left navigation pane applications, I can directly go through the history. What is the record? Yeah, this one is the record. As you can see, the updated field is read-only and the short description is mandated. There is a value. That's why it is greyed out.

But if I remove the value, you can see it is mandated. And now you can see that the price field is hidden. Earlier, there was a price field over here. It is right now hidden. So how is this happening through this UI policy? Let me come back to the UI policy. Here we have something called Advanced View. Let's make sure that we are on Advanced View.Now let's try to understand each and every field that is present in this UI Policy form. So the first thing is the conditions earlier. We haven't set any conditions, which means thisUI policy will run on all the conditions. Whatever the field values are, whatever the state is, whatever the field values are, this UI policy will be executed. Let's say I'm going to put a condition. Caller is not empty, which means if the caller value is filled, the collar is a field in the vulnerability management form. When that is filled, then the UI Policy will run. Let me save and update this automatically. We can see that it is redirecting to the vulnerability page. Now we can still see that particular UI policy is running. It is mandated, updated and read only. There is a field at the bottom called Caller, and it is filled with John Ball. Let me go to the form layout and bring this field to the top so I can keep it. Just let me get the end split. So that's it. This is the form.

As you can see, the caller is filled in, the update is read only, a short description is mandatory, and the price field is hidden. Let me clarify this value. You can see that there is some change in the form. This is not mandated. This is again editable. Now we are able to see basically what is happening. What's happening is the UI policy is running. Whenever there is some change in the form, Whenever there is some change in the form, the UIpolicy verifies whether the condition is matched or not. The caller's information should be filled in. As the caller is empty, the UI policy is reversed. If I'm adding the field, I mean, if I'm adding the user back again, you can see that UI policy is getting executed. The price field is again hidden. This is how the UI policy will work. Let's get back to the UI policy again. There are certain other fields. We mustn't understand this. First, we have the global. We already talked about different views of the home. So this game is something which is related to that. When should this UI policy run? Should it run on all the views or only on some particular views? If you are selecting global, then this UIpolicy will be executed on all the views. If not, if I uncheck it,I can select a particular view. Let us keep it global for now and then we can reverse it.

If false, if this condition is met,then the price field will be visible. If that condition is not met, what should happen then? If, let's say, I'm unselecting this, if the condition is met, the price field will be visible. False If the condition is not met, thisvisibility will not be changed at all. But if I'm selecting this, it will make sure that if the condition is not matched, this visibility will be true. If the conditions are met, these things will run. If the conditions are not met,these things will be reversed. If it is false, then it will become true. If it is true, then it will become false. If it is left alone, nothing will happen. Then we have to load it. So let me uncheck this and update it. Now we'll be redirected to the form. You can see that I haven't modified anything right now. The form has just loaded. The caller field is still there. But even then, we are able to see the price field. The update is editable and the short description is not mandated. What exactly is happening? The UI policy is actually not running right now. But if I remove the value and then add it again, you can see the UI policy is running. This is the difference. Basically, by default, all the UI policies run. When there is any change in the form, that is nothing but a change. But if you want to run these UI policies onload, then you must make sure that there is thisonload thing, which is right now inactive.

So, as in the earlier example, we have loaded the form and we have seen that the condition is met. But the UI policy is not running. That is because we have unchecked it. If I check this and if I update it now, the form will be loaded again. The vulnerability record automatically As you can see, the short description is mandated, the updated is there, and the price field is hidden. So load up. Also, the UA policy is working now. That is what the UA policy is. Then there's the inheritance. Inherit is something related to the extent of a stable concept. Like task table is a parent and incident problem change, as we all know. All those are the children's tables. If we are creating any UI policy on the parent table, like the task table, should that impact all the child tables or not? That is defined over here. If I inherit this particular UI policy, then the child tables will also have this UI policy. If I do not inherit it, then this will not impact the child tables at all.

So that is the UI policy thing. Finally, we have one more thing called "script." Whatever we did is just like dragging and dropping the fields, like creating a new field and all. Instead, if you want to execute any scripts, then you can check this option. And if the condition is met, this script will run. If the condition is not met, this script will run. We can write all the client-side scripting over here. Basically, the Java script can be written over here. We'll be discussing this in the client scripts, which we are going to discuss in the next session. So that's it related to the UI policies in one line. What exactly is UI policy? Why do we do it? UI policy allows for doing three things. Making a field mandatory, or making a field visible, or making a field read only by you.

3. Client Script

In this session we are going to discuss the client scripts. As discussed in our first session of this particular section, the client scripts are the ones that run on the client, which means the browser. Basically, we write JavaScript over these particular client scripts. How can we access it? Simply type client scripts in the left navigation pane, and it will appear under system definitions. This is also another table. It has all the client scripts that are present in the current service. Now system, let's say I'm going to create an aclient script and this should be on which table? Let's say one multi-management table. Let's select our vulnerability management table well. The name is something which is just for our reference so that we can understand what this particular transcript is doing. Let's collect for this example. I'm going to throw a pop up. So let me give the name as a pop-up example.

UI type When should this particular client script run? Where should this client script be executed? Should it run only on the desktop application or on the mobile application also? Or on both. For now, let's keep it all active. If the client script is active, that means this client script will be executed. If the client script is inactive, then the script will not impact the form at all. Inherited, it's the same as a UI policy. If we are going to check this, the childtables will also have this client script. If you are unchecking it, then only the parent table will have the client script. The child tables will not be impacted by this client script. This is related to the view. If you want to run this clientscript over all the views, check this. Or if you want this only for one particular view, then uncheck it and write the view name. For now, I'm going to keep it's global description a bit more descriptive regarding the current line script,like what exactly that is going to do. Messages are related to the UI thing where you can put some messages and you can utilise those messages in the scripting part. Now, the most important thing is the type. There are four types of client scripts based on when the client script is going to run. There are four types.

The first one, let me click on it, and you will be able to see it. There are four types. The first one is on sale. Then on Change, on Load, and on Submit. The "on sale" edit is something related to the list layout. Let me talk about the list on Onslated. Before that, we'll discuss all the other changes, on Load and on Submit. First, let us try to understand the loadclient script when the form is getting loaded. If you want to run some scripts, you can select the type on load. You can see that the function is populated over here automatically. Which means this script, whatever script I want to write, I must make sure that it's present in this particular function only. Let's say I'm going to throw a pop up.So for that, the script is alert. This is a small syntax. This line, this particular line, what it does is it throws a pop up with this particular text. Let's see how it works. And as I said, this is on load. So let me put that statement over here. Let us go back to our vulnerability ticket. So you can see that the onload script is running. This is because of some things in society that are getting copied. That's fine. So this is the way we are going to pop up a particular message.

Whatever we want, we can show it over the pop up.This is the way. Now, as you can see, just as the form is loaded, the popup has been shown. Let us create another client script and this time we will select a different type of change. Once we select on change, there is a new field shown over here, which is the field name onchange of what field should this script run? Now we can see all the fields that are available on this particular vulnerability management table. So the duration field, HTML field, and all the other fields available on that table. Let's say on change, what should we keep? Let's say on change of, let's say on change of short description, let's throw a pop up.Depending upon the type, the function name is also changed. This is not something which we do, it automatically gets populated. Nothing to be worried about. The syntax is over here inside this function. We need to write our code.

Let's say again, I'm putting a pop up over here. So this is an example for on change. I'm going to give the name example, then submit the record. Let's go back to our vulnerability record. You can see the popup. It is on load. Now let's say I'm modifying the description. Remember that we changed the client scripton to short description, not description. So I'm just modifying the description and I'm clicking everywhere. Nothing has happened. Now let's say I'm modifying a short description. Now you can see the pop up example of the change. Whatever changes I make, actually, that particular client script will not run unless I change the shortdescription field, then the change will run. The difference between on load and on change is just during the form loading. If you want to run the script, we are going to put it on load, and if you want the script to be run after modifying a particular value or particular field, we'll use the on change plan script. Let's look into it before that. Let me, as you can see, as you have seen, let me add one, two, three, testone, two, three, and I'm saving the record before the change. The pop-up has come again.

So I'm now saving the record. You can see there are no extra pop ups.It just got saved. Once the form is loaded again, the onload script is running. Let me create a new client script, then the name is on submit. All the other things will be the same. The table, all the things the type is on submit. Now you can see the function name is again changed on submit. So that's it. Let's see when this particular client script will run. The form is loaded, so the on load script is running, and if I am modifying the short description, the on change client script is running. Let's say, as you have seen, I have modified a certain short description. I'm going to modify the description to let me put in the latest test, and I'm going to save the record now. Now we can see that there is another pop-up example for Onsubit. This is the on-submit script. This is how the scripts run when the form is loaded. On load, client scripts will run. When the form is being modified or when a particular field value is modified on the form, then the on change client scripts run, and finally, when the form is being submitted or saved, then the on submit client scripts will run, depending upon the situations you need to properly judge where exactly the script should be running. There is one more client script called "on low on sell edit."

This is actually not a frequently used one. It is very rarely used. Let's say, for example, I'm going to the one liability management list layout. This is the list layout of the particular table. If I modify any value, let's say if I'mmodifying the percentage, then if you want to run certain scripts, then you can use the onsell editor. So, that is something which is very rarely used. So there's no need to be concerned about that. Let's get a bit more in depth into the client scripts. Now let's take a small sort of assignment and understand what the different types of scripts are that we can run in the client scripts. So now I'm going to inactivate all these clientscripts that we have created. I can click on control and click on the button on the cells so that I can modify them. I can do a bulk update as I have set them to false. No client script will run. Let's say we have a requirement where let's go to the problem table first. Here we have a field called "configuration item." This is a reference field. If I place my cursor over this icon in any of the reference fields, If we select any value, any record over here, we'll be able to see the icon. If we hover on the icon, we will see the record details of the selected record. Right now, as you can see, I have selected iron mail or iron Yeah, that's iron mail. If I hover on it, it should show the details of the particular record.

It is taking some time to load. Let's say, for example, if I'm clicking on this lensicon, I will see all the list of configuration items. As you can see, these are the CIS. There is a field called "Let me bring the field called "Support group." Basically, if you are talking about any CI, that particular CI can be controlled or can be supported by a team that is nothing but the support team. Let's filter out the empty ones. Let's say this is the requirement. Okay, let's say on the problem, if I'm going to select a CI which has a support group, then automatically that particular support group will be populated over the assignment group. Okay, so this is the requirement. Let's try to understand which type of client script should be utilised over here. What is the requirement if the user selects a particular CI? The support group should be populated with the assignment group. The first one, the first type of client script On load, it runs only on the load of the form. Right now, that is not the case. Once the CI is selected, it should be populated. So on load will not work because that will run only during the loading of the form. The next thing is the change. Change is exactly what we need now. We'll populate the support group over here when the CI changes. What type of script are we going to write that we are going to see soon? But this is what we need to do. Then let's look into the last type of client script which is on submission. Once the record is submitted, the assignment group will be populated. This is not the thing that we are looking for.

So now we should create a change client script. Let's create a client script. The other way of creating a client script is directly when you are on the problem ticket or whatever the table you are on. If you want to create a client script for this particular table, you can right click over the top, go to Configure, and then go to Clients. In the same way, you can create UI policies. Also, For now, I'm creating client scripts and creating a new client script. Then, as we discussed, it's an on-change change of which field configuration item field. Allow me to insert the name of the populated support group. This is a place where we are going to write the script. Before getting the proper syntax, Let's try to write a pseudocode for this particular script. What should be done? First, get the CI name. Once we get the CI name, we query the CI table to get the support group of the selected CI. right? First we need to get the CI which has been selected. Once we get the CI, then we need to get the support group for that particular CI and finally set that support group in the assignment group field. So these are the steps that we are going to take. Now, let's get into the real syntax. How can we get the CI name? So what exactly is the CI? Right now it is just a field on the form. If we are going to set certain values in a particular field, how can we get them for that? There are now APIs and objects in services that allow us to obtain this type of information. Okay, that is called the G underscore form object. It is an object, and it has certain functions with that object.

And with those functions, we can do certain activities like getting the field name, sorry, getting the field value, setting the field value, all sorts of things. Let's take a look at g underscore form dot. If you type this G underscore form dot,then you will be able to see all the functions available in this particular object. Assume G underscore form dot value. So which particular field are we looking for? Cmdbci. Let me just save this update to this client script. As long as there is this error, I won't be able to save. So let me comment on this pseudo code. I'm coming back to the problem ticket. Right here we can see this field, right? So we need to get this value. We can see the value if we right-click on it. So when we were creating the dictionary fields or the fields, you must have remembered that there are two things. One is a label and name. The label is what the user sees on the outside,which is the display name, the configuration item. But a name is something which is stored internally. And whenever we are writing certain scripts, we need to use the name but not the label. So this is CMDB. Underscore CI. In the same way, assignmentgroup is an assignment underline group. Let me come back to the client script. So this is the reason why I have used that particular CMDB underscore CI to get that particular value. If I write an alert, you'll be able to see its value as it is a reference record. We'll be getting the CIS ID of that particular selected CI

A CIS ID is something that is a unique number. And we have discussed this in our previous classes. And how can we query the CI table and get the support group of selected CI? We know that CMDB CI is a field on the form. Basically, it's a reference field that references the CMDB table. There is an object again, the GND score form. In this object there is a function through which we can get all the data related to that particular selected CI. So the CI has a name, and the CI has a support group. CI has some operational status. the selected CI. Again, it's as if it is a record,it will have lots of data. If we want to get the data directly, we can actually write Gndform, get reference, and then the field name. So if I write this, what happens is let's say I'm going to store this CIO BJ. I'm going to store this reference in the CI object. And then finally, what I can do is if I write something like alert CIO BJ, dot name,what this does is actually in this object we have all the data related to the selected CI. If I write dot name, it will give me the name. If I write to the support group, it will give me the support group. So first I'm going to set up a support group. Sorry, just the name. And let's see how we'll be able to see it.

This is the value of the CIrecord, which means we'll get the CCI. So let me change this CI. So I selected the CI immediately. It has popped up with the CID of the selected CI. And then the next pop-up will be the name of the CI. CSAP SRV One. This is the one which I have selected. So that's it. That is how the G underscore reference works. Now what do we need? We need a support group for that. What we can do is simply go to our clientscript and then here we can write support underscore group. That's it. With this, we'll be able to get the support groupof the selected CI and let's not alert it. Instead, what we need to do is to reassign the particular support group in the assignment group. So we'll use G underscore form dot set value. This is another function where you can set a value in a field. This is the syntax assignment underscore group. I'm going to set a value for this field. And the value is this one. Okay, let's see how this works. Basically, we have three lines, three pseudo-code lines. First we need to get the CI and then we need to get the support group for the CI. And then we should set the assignment group. So, with this reference, basically directly we are able to get the support group. Instead of working on the CI name, we are directly getting the support group. So there is no need for this alert at all. There is no need to get the value directly because the reference is doing all the work. Let's modify the CI.

There must be no assignment group or there must be no support group for this API guess. Let us select a CI that has a support group. Okay, I guess there is a small mistake in the government script. Let me check this. As you can see, the spelling assignment group is wrong. That is the mistake. This is the current spelling, right? Assignment: Underline group Now let's try our script. Yes, so that's it. The security is copied. So the mistake that we made is that the name of the field name is wrong. That's it. So this is how we can use the client script. As you can see, this script is running on the server. On the client side, the user is able to fill in this particular script. So, this type of script is nothing but a client script. There are many things regarding this client script. There is an object called the g underscore form. There is an object called "g underscore user." As you have seen, there are these different objects, and there are many functions inside those objects. How can we understand those objects? I mean, how can we get information about those objects? It is basically from the wiki service now.com. Let's go to the wiki service now and try to get information from there. As you can see, I'm on Google now and I'm searching for, let's say, wiki instead. I can directly search for g underscore form service. Now you can see this g underscore form. If I click on this, it will give us all the functions that this particular g underscore form has.

There are numerous functions available, such as adddecoration, flash, and get label off. The ones that we have worked upon are listed for reference. So this is the one which we have worked on. If we click on that, we'll understand it will give usclear details like what this particular function does in the same way we worked on getting value. So if we click on it again, it gives us the syntax and how we can write an example. all these things. So this is what we actually need to do. We need to go to the EB key and we need to try and understand the different types of functions which the g underscore form provides. In the same way, there is one more object called g underscore user.Again, this is related to the current user session. Like, what is the user name who has logged in? What is his user ID? All those things we can get from this g underscore user object. So go through these two objects, gunderscore user and g underscore form, and you'll understand what the different functionalities are in this particular object. As this is purely an admin part, we are not going to COVID all these scripting things right now. So that's it. Regarding the client scripts, I hope everyone understood this. If something is not clear, make sure that you understand it clearly. You just come back to the previous sessions again to learn this whole client script concept again.

Prepared by Top Experts, the top IT Trainers ensure that when it comes to your IT exam prep and you can count on ExamSnap ServiceNow Certified System Administrator certification video training course that goes in line with the corresponding ServiceNow CSA exam dumps, study guide, and practice test questions & answers.