All ServiceNow CSA certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the CSA ServiceNow Certified System Administrator practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

Core Configurations

4. UI Action

In this section, we are going to discuss UI actions. What are UI actions? UI actions are the actionable items. We can see certain links or buttons on the phone whenever we click on them. Whenever the user "actions" on that particular button, "actioning is nothing more than clicking on it. Okay, so whenever the user clicks on that button, then there will be a certain script, and that script will be executed. That is the UI action. Basically, whatever buttons we see on the form are the UI actions.

Let's create one UI action. Just type UI Actions on the left navigation pane, and you will see the UI Actions under System Definition or under System UI. These are all existing UI actions that are present in the current system. You're going to create a new UI action. name is what you see over the button right now. You can see the submit button over here. That is also a UI action. So the name is nothing but what you see on the button. On what table should this UI action be available? I'm clicking on the table, and I can see the order. So if there are four to five UIActions, which one should be displayed first and which one should be displayed last? That depends upon the order action name. This is used for scripting in Active. If it is active only, then the UAction will be the button that is displayed.

If not, the button will not be displayed. Show insert. Show update. Show insert is nothing. But whenever we are creating a new record in the table, in this particular vulnerability management table, if you are creating a record, it has not yet been created yet. Okay, we are creating a record whenever we are creating it. If you want the button to appear, then you must check this box. If you are opening an existing record, then if you want to see the button, then you need to check this update. We'll be discussing that very soon. like how exactly those differ. And on the right side, we can see all the checkboxes. These are all different places. A form button is a place. This is a form button. If we want the button over here, we'll click this form button. If we want it over the context menu. Saving is a button. If you want that thing over here, then you can check the form context menu. Or if you come underneath, I'm not sure whether it's available here or not. Let me save the record. I'm just selecting the form's Submit reform button. If I go back to the vulnerability record, yes, here it is. This is the button that we have created and which will be displayed at the bottom. also the test UI. Now let's go to the UI action again.

I'm going to select from the context menu. I'm coming back to the vulnerability record again. Now if I right-click, I can see the test UI. So this is because of the context menu. So in the same way, Let's say the form link is displayed underneath the form. It's a related link. You can see this test UI. There is actually no much difference for all those. The form button, the form context, the menu—all these are only where the button should be displayed. That's it. If you are checking something, it doesn't mean that the script will run in a different way. It's only like, where should this button be displayed? Just test all these things. These three things are on the form, and these are on the list. Let's say if I go to the vulnerability regard, I cannot see the "Test UI" button anywhere. Even over here, or even here, nowhere. If I go to the test UI action and select these choices, you can see that they are displayed over the top. again over here. Again, even in the related links over this list choice, even over here So this is list-related stuff.

Try to understand. Just check only one particular thing, like a list banner button, and check where exactly that is being displayed. So test yourself and understand where all the positions of these form buttons can be. The UI action can be displayed. Coming to this part, this is much more important than the condition and the script. So before going into that, let's understand the show insert and update. Let's say, for example, that I am only showing it on the insert. I'm not showing it on Update. I'm going to look at the vulnerability records. I have selected "Insert." I'm opening an existing record. It is not displayed over here. Now, if I go back to the vulnerability records and create a new record, remember, this has not yet been created yet. We have yet to create it. Now we are able to see the button. This is the show insert. If we want it during the update, like if I'm opening an existing record, if we want the button, then check the Show update. Now I'm only making the show update. Let's see the difference.

Now, if I go to the vulnerability management section and go to this existing record, I can see the button, which means updates are enabled. If I try to create a new vulnerability record, then the UI action is not visible, which means Show insert is unchecked. That's it. There is a feature called list vs. three. Depending on that, these two things will be useful. But right now, we are not going to discuss that. Now, I said earlier that there are two types of scripts. One is client-side, and another is server-side. The two things about which we have spoken so far are UI policies and client scripts. Both of these things run on the client side, which means we can write client-side scripting things. Earlier, we spoke about the G underscore form object and the G underscore user object. Those are available only on the client side. If we are using those objects on the server side, they will be of no use at all. We will not be able to access those objects at all on the server side. Now we are able to see the script in these UI actions. Which script should be written over here? Should we write client scripts, client-side scripting, or server-side scripting that is defined by the client? So this is something special in UI action.

Client scripts and UI policies can contain only client-side scripting. Business rules and scripting routes can contain only server-side scripting. But UI action is our choice. We can make it run on the client side or on the server side. If we check this, then the UI action will be on the client side. If we uncheck this, then this will run on the server side. Let's say if I'm checking it, the only thing I need to make sure of is the click. I need to write a function. I need to write something like this. Inside this, I can write the whole script. This is something that is mandatory. If we are checking this, we need to make sure that we are just calling the function here and that we are defining the function over here. Inside this, you can write all the client-side scripting that we have seen earlier. For now, I'm going to use the server side. So for the server side, that is not required. I can write this server-side code directly. This is one of the codecurrent dot field names equals to. This is server-side code. This is the way of writing on the server side.

Current is the object, and it has all the details regarding the current record, which we are updating. We have two records and one ability record. If we open a record, then if we click on this button on this particular UI action, the current object, what it does is it picks up all the current record details, like the short description, the price field, the description value, the number, all those. We can access them directly via this currentfield name, and we can set the values. And finally, we need to write this line so that it will be updated. The short description field name is actually "short description." So I'm going to write this and save it. Now let's go to the existing vulnerability record. We can see the button. You can see test 1236 there right now for ticket 1. If I click on "Test UYA," let's go to the vulnerability records again. I'm going to play the same record again. You can see the short description has changed. So this is coming from the UI action that we have created.

So that way, we can write the scripts in the UI actions. One last thing regarding the UI action is the condition. There will be many cases where you don't want the user to see the UI action all the time. Let's say we have a thing called a "resolve" button on the incident form. When a ticket is in the "New" state or "New in Progress" state, a user can resolve the ticket. Suppose a ticket is already resolved; then there is no use in showing the Resolve button. Let's see the form. Incident Table I'm going to open the open tickets. I'm opening a ticket that is in the "in progress" state. We can see the "Resolve" button. If I click on the Resolve button, the state will be changed to Resolve. So that is what this particular UI action does. But say if I'm opening a record that's already resolved. Should I see the button?

No, there is no point in showing that UI action for that reason. What we do is, let's say, if I'm going to the UI action that we have created, there is a thing called a condition. In this condition, we can mention when this particular UI action should be visible. Only if this condition is met, the UI action will be visible. Let's see a small example of this. Let's say the current dot-underscore description description is equal to "empty." This means if the current description is empty or the description field is empty, the button will be shown. If not, the button will not be shown. Let us check this out. I am opening a record that has some existing descriptions. Let me reload the form again. Yes, it has some description, but we're not able to see it. If I clear it, I'm going to save the record. Now you can see the button. So this is how the condition works. If a particular condition is met, only then will the UI action be shown.

You can use the current objects over there to get the current details. Like if you want to get the state if the state is in progress only, then we need to show that, and then you can write something like "current dot state equals in progress," or something like that. You can also add multiple conditions by using and operations or and operations. Let me show you. If you are looking for something like "current dot," the description is empty, or let's say "current dot," you underscore the short description as equal to empty. So if either of these two fields is empty, then the button will be shown. Else, you can write something like this and use two percent symbols, which means that if both conditions are met, only then will the button be shown. So this is the difference between "and" or "conditions." That's it. Regarding the UI actions, basically, in simple words, what we can define the UI actions as are the buttons, which, if clicked, will cause certain scripts to be running. That's it. There are buttons. If you click on those buttons, we will run the script. That's it.

5. Business Rules

In this video, we are going to understand the business rules concept in ServiceNow. Before getting into business rules, there is a concept that I feel is very much related to business rules. If we understand a concept called AOP, aspect-oriented programming will be able to understand business rules very easily. What exactly is AOP? Let's try to understand that first. Let's say there is a transaction. We can take a banking transaction as an example. like transferring a certain amount of money from one account to another account. Transferring from the source account to the target account This is a transaction. In this transaction, basically, I can say there will be two things. There is a start point, and again, there is an end point. Okay, the transaction will start.

I mean, the account will be transferred from this account to the other account. In this transaction, we can inject certain functionalities, like running certain functions during the whole transaction. We can insert these functions at the starting point. Just before the transaction is going to happen, we can do certain validations, like determining whether the amount is correct and whether the account holder has the prescribed amount of money or not. Like if he's transferring some $10,000, then does his account hold that particular amount or not? We can do that validation, right? So, as this is a transaction, we are verifying whether the person has transaction money or not. This is something that has to be done before the transaction starts. At the same time, once the transaction is complete, we can also do many more functional checks. like whether he has the proper rights to transfer the money or not.

So many other things And at the end, once the amount is transferred to the target account, we can again perform some more functions. Like we can verify whether the amount is debited from the source account or not. And we can also send some notifications to both customers. Like, your account has been debited and your account has been credited for both parties. So this is something that has to be done at the end of the transaction. If you are taking a transaction, we can do certain things or add certain functionalities at the start, at the end, or in between. Okay, this is a very important concept. This will help us actually understand the business rule concepts very easily. Now, let's get back to the service now. System Let's create a business rule. How can we create it? Just type "business rules" in the left navigation pane. Under the system definition, we'll be able to see the business rules again.

This is a table. We are going to make a record of this. I'm going to click on "new." Let me minimise the left navigation. I can give it a name. Let's say test. I can give you the table's name. I'm going to select the vulnerability management table again, and then when to run this is something that is important. So before that, let me save the record. Now we have something called "advanced." I'm going to click on this. Now we can see certain extra fleets. Let's now try to understand the business rules. What exactly is a business rule? There is a transaction, and in the transaction, if you want to run certain scripts, you can use the business rules. Now, what is a transaction? If a record is being updated or if a record is being created in the system, If a new incident record is being created before the incident record is created if you want to run some script, or after the incident record is created if you want to run some script, then you can utilise the business rule. Okay, let's see how we can use it. We have learned that these two things are very important. before and after. is the most frequently used business tool. Before is nothing, but let's say if I am saving a record, before updating the record into the database, my script will run.

If I'm going to set the before option, if I'm selecting after updating the record in the database, my script will run. So before updating the recorder after updating the record, So if I select the update, then that happens. If I'm going to create a new record at that moment, if we want to run the business rule, we can select the insert. We can also select both. It's up to us in the same way. If you want to run the script before or after deleting the record, you can select this option before making any queries to the stable. You can do this again on top of these before and after, and we have Async and Display. Async is something that runs like a scheduled job. Once we select async, it will create a scheduled job with the current script, which will be executed after a while once the transaction is complete and the record is updated. After a minute, or maybe after ten minutes, depending on the system's time, the business rule will run. So this is something that is rarely used and is mainly used in integrations, not for usual purposes.

Display is something that basically happens whenever we are opening a record; you can consider it onload whenever we are opening a record, and if you want to run the script, you can utilise it. For now, let's select display. We have ordered again the same thing depending upon the order the business rules run on a table. If there are a hundred business rules, which business rules should run first? That will depend upon the order that is mentioned over here. The next thing we need to look at is this actions section. In this section, we can actually set some values. Before that, let's get into the conditions again. This business rule As I said, this business rule will run whenever there is a transaction, and just before the transaction, if you want to run the business rule, you'll be doing it.

But there are thousands of records. Let's say you are talking about incidents. There are thousands of records in the incident table. Should this business rule apply to all incident records or not? That is defined over here if this condition is met. As an example, say that State Right now has selected the vulnerability table. So I'll be able to select only those fields. Let's say the choice has a choice field, right? If the choice is option one only, then run this business rule. If not, do not follow this business rule. That is what the condition makes, and at that moment, we can set some values. If the choice is one, then set the caller to two. Let's take a user record. Let's say an ATF user. What this means is that when the user's choice field is set to option 1, automatically the action will be set to 80 for all users. The other thing we can do is add a message. It will show a message. We have seen the alert, right? So it is a pop-up. Instead, we can show a small message. We will be seeing it soon again. Here we can write the scripts, and if the condition is met over there, the script will be executed. Here we are going to write the server-side code.

As I said earlier, we can use the current object, and there is one more object called previous. There is one more object called the Gsglide system. We can write GS. Get the user ID. No GS. Now, to get the current time, there are many functions related to the GS object. We'll be going to the wiki, or once the business rules are finished, we will be going through the wiki, and we'll see what all objects are available on the server side. Now coming back to the business rules, we can write all the client-side or server-side scripting over here. This script will be executed only if this condition is met. Right now, the condition is blank. But we can write any condition over here. Current dot. Let's say something like "state equals resolveonly" and then run the script or something like that. Depending on the requirement, you can set the condition. Let's say right now I have said this too much. Whenever we are opening a record, we are going to send a message called high, and the caller is also set to an ADF user. Let's see how this works.

Of course, let's remove these set values directly. Let's have the message. I'm going back to one of the vulnerability records. You can see the message now. So this is how we are going to use the display. Just before opening the form, we can add the script, like whatever script we want, we can add, but right now I have used that add message. Let's get back to the business rules. Again, this is the business rule. As I said, let us remove this. What we can do is something like this: before an update, if the choice field is set to Option 1, then in the actions I'm going to set the user as the change manager.

Okay, I'm updating the record. I'm going back to vulnerability. What I have done is, if the option is selected, let's say this is updated something like this: Now, as you can see, the choice field is option 1, and the caller is John Paul. Right now, I'm going to save this. BR is nothing but business rules. It's a short form. You can see that the caller is changed automatically. This is how we can use the business rules before updating the record automatically.

It has modified it again; let's go to the business rule. In the business rule, we have one more thing called an abort action. What we can do is when this particular condition is metabolic action, which means the change will not be saved in the database the change is about to get. That is one of the options that you can use. So this is the business rule, if you want to describe the business rule. What we can say is that business rules are something; they are certain scripts that can be executed before or after updating a record, or, sorry, before or after updating or inserting a record on top of it. We can also run the scripts while displaying a record. So these are all things you can remember. This is the business rule is. Whenever there is a transaction in the database, like creation, update, deletion, or querying before or after that, you can execute some script through the business rules. In the next class, we are going to discuss what objects are available on the server side and what objects are available on the client side.

We are not going to experiment on all those things because, as this is just administrative work, getting this knowledge is sufficient. But I would like to introduce you to your coding partner. But we are not going to practise all of them. We are going to see what our objects are available from the service now.

6. Server & Client Objects

ServiceNow provides certain objects "out of the box." When we are writing scripts on the server side, we have, I would say, primarily, two objects. One is GS, and the current system is nothing, but it's the same as GS and the previous one. It is actually almost never used. I would say that in about 5% of the cases, we'll be using the previous object almost all the time we use the current object. You can understand exactly what these two are. So basically, as I said in our earlier classes, the current object and GS object can be used in the server-side scripting whenever we are writing business rules or whenever we are writing the UI actions.

And if that UI action is running server-side, we can use both objects. But when we are writing client-side scripting, then we have two objects. Of course, there are some more objects, but mostly two are used. One is the G underscore form, and the other is the G underscore user. You can search for those objects in the Wiki services now again, and you'll be getting more information regarding that. So on top of that, I can say that four objects are important while doing scripting server-side, and there are two. One is GS object and current object. Client-side, there are two. One is the G underscore form, and another is the G underscore user. This actually ends our core configuration related to the service. Now we are going to the next chapter, which is about a bit more advanced configurations like creating emails, sending events, and all these other things.

General Configurations

1. Events

In this session, we are going to talk about the events in service. Now, first of all, what exactly is an event? If we are taking in any process, it could be an incident process or a problem process—any process. If a particular is reached or a particular point is reached, then we can actually create an event. Let's say first of all, how can we create an event? Just type registry, and under system policy, under events, you can see the registry. This actually shows all the records or all the events that are available in the current system; there are 416 events.

I'm going to create a new one for us. Let's call it. Now what we are going to do is, as I said, what exactly is an event? Whenever a particular thing has happened in a functionality, whenever we are reaching certain goals or reaching a certain point in our particular functionality, if we want that point to be noted, then we create an event over that particular place or that particular functional or logical place.

Now let's say we want to create an event whenever the caller is filled in our vulnerability management record, which means whenever we already know that we have a field called "caller" on the vulnerability form. Let's say if a caller is filled or if a user is added to that particular field, then we need to trigger this event. If that is the case, let's see how we can do it. We need to name it. Let's name the event as "well, cooler added," and then we need to select the table where this particular event is triggered. Let's select our vulnerability record vulnerability table by. So first of all, description is something just for our reference purpose so that we can understand what this event does, and fired by is also a descriptive part for us, which is just for our information. This. Actually, what we need to do is write down the location where this particular event is triggered so that it will be easy for us to modify those things if it is required in the future. Let's say I'm going to trigger this in a business rule, and the name of the business rule will be, let's say, "caller added." So this is something that we are going to create now. This is how we create events. Now let's trigger this particular event. I'm going to follow business rules.

First of all, I will just deactivate this one, the one we created earlier, and let me create a new one. This is caller added, and then the table name is vulnerability. Let's have the advanced features also when to run is before inserting or updating. What we want is if the caller is not empty. Okay, so this is the condition that we are going to put, let's say something like advanced. Now in this script, we are going to create the trigger for the event. Before that, we need to add one more condition for proper triggering. So that would be a caller change from "let's keep it blank." So if the caller changes from empty, then this is going to trigger this actually working. But for now, we can just remove this filter and let's move ahead. In the advanced section, let's add the line that will actually trigger the event. The script for that is the GS event queue. And here we need to mention the event's name. It has a vulnerability added; I guess this is the one that I created. And then we have some more arguments, which are to be written over here. The second argument will be a glide record, let's say. Let's simply put it as "current" for now. If we are not, first of all, let's fill up the whole line, and the next one would be a parameter. And then the second is parameter two. So this is how we can trigger an event. So inside this, we can actually set certain values.

We can send the caller's details or any other details. And whenever we are notified of this particular event, we usually catch it in the notifications. In those notifications, we can select "What do you call that?" The param one and param two Let's say I'm going to put something like "current caller." So this is a field that we have created. What this does is give this value. It actually transfers this value along with the event. Wherever we are going to catch this event, this can be utilised in the same way. This is another parameter. We can also utilise this second parameter also.But for now, let's keep it just black. So this is how we trigger the event. Two things can be done with this. One is that we can write script actions. With the script actions, what we can do is if this event is triggered, we can run certain scripts. So in script actions, if we click on New, we can select the event name, and underneath it, we can write the script. So if this particular event is triggered, the script underneath will be executed. The other thing we can do with the event is create the notification. So this is what we are going to discuss in our next class, and it's related to the events.

2. Email Notifications

One of the common requirements when we are administering services now is creating email notifications or modifying email notifications. Whenever an incident is created, we may need to send a notification to the person who has opened the incident.

Whenever it is assigned to a user, we should also send a notification to him stating that an incident is assigned to him. There are many other situations, so how can we create the notifications? That is what we are going to discuss in this current class. To create the notifications, go to the left navigation pane and type notifications under System Notifications. We can see the notifications here. We can see all the existing notifications created. There is a notification on the catalogue task table for the incident. Let's create a new notification for our vulnerability management.

Whenever a vulnerability record is created, we should send a notification to the caller of that particular vulnerability ticket. The name is something that is not appropriate for our purpose. for reference purposes. For reference purposes, let's call it notify the caller. The table is our vulnerability management plan. So we need to select that particular table. Over here, we can select any category and the classic field, "active." If this is checked, the notification will be triggered. If not, the notification will not be triggered. Then we have inserted or updated What exactly do these two things mean? Whenever a record is getting inserted, if you want to send a notification, you can check this. Whenever a record is getting updated, if you want to send a notification, then you need to check this. Usually, an example of this is whenever a record is created, we need to send a notification to the caller that a ticket has been opened for you in the service number system.

So something like that That is when we need to insert an update if something like a ticket is already existing, and let's say if it is assigned to a group or a person, then we need to send a notification that at that moment will be using the update. Depending on the situation, you can select any of these or both of them. When should we send this notification? If you are talking about notifying the caller, this is only during the creation. In this case, we can say that there is no need to add any conditions. Let's say if we are sending the email whenever it is assigned to a person, then what we need to do is set a condition that the person it is assigned to is changed. Something like that Let me select the incident table, or what we can do is go to the existing notifications and see how exactly they are created in service now out of the box. We'll be going through that once this particular notification is filled.

So I'm not going to have any conditions. Who will receive this? We are going to mention who will receive it, like who are the recipients of the email? If we want to specify any particular user in the system, you can use this. You can click on the lens icon, and you will be able to see the number of all the users in the table in the system. Like the John Paul, whatever email is selected is available over here. It will be sent to that person via email. If I select an ATF user, an email will be sent to this particular email ID. If I want to add anything manually, then I can do this. like something like this. If I want to add any group, this is usually useful when we are talking about sending an email to a group. Whenever a ticket is assigned to a group, if we want to send an email to all the group members, we can use this feature. And then this is something related to the current existing table. I have selected the vulnerability management table. It is showing all the fields in this particular table. Now in our case, we need to send it to the caller. So this is what we need to select, and that's it. The last thing is what it will contain. What we can do is create a subject. What is the subject of the email? A view is created, or something like that. And in the body we can write that Hi Vul is created for you. These are the details.

And now we can actually get information about the current record. If a new record is created, we can access those field values over here. Just click on this, and you'll be able to access all the fields. Let's say description. Just click on the field automatically. It will be added to the body's short description. So this way, we can actually configure the body of the particular email notification. So that's it. Let's try this notification. I'm going to create a new record in our vulnerability management table. Before that, we need to make sure that we have enabled email outgoing and ingoing for that. Just type email properties in here, and you'll be able to see that email sending is enabled. Make sure that this is yes; only then will an email be sent from the ServiceNow system. One more thing is that we can also send emails to ServiceNow, and it will parse that email and create the tickets. Of course, there is some extra scripting logic that has to be done to receive the emails. Make sure that email receiving enabled is true for sending, which is outbound. This has to be true for inbound this has to be true.

Now let's go and create the vulnerability record. There are a few more things that need to be taken care of. Let's say, first of all, let me create the record. I'm going to set the caller so that at least he will receive the email, and I need to set this short description and also the description if I save now. Actually, the email will be sent to the user. This is John Paul. But how can we get to know whether the record is sent or not? It is actually stored in the activities. Right now, we don't have any activities. Let me describe the activities over the phone. Just go to the form layout. We can see this activity. Bring it over to the form. And here you can see this icon. So here again, we need to configure variables. We have sent or received emails. Well, when should I check this? Yes, it is actually enabled. So I'm refreshing the page. Now let's see whether the notification is available or not. Yes, it has come. Of course, it has taken a certain amount of time, about two minutes. It was created around 25-50, but it got executed, or it got sent, at around 27.

Because of the system, there will be certain because of the system. There will be a lot of scheduling, jobs, and all those things. So that's how we send the notification. And again, if we want, we can change the settings to let me go to the email notification again. We can also mark it as updated and set certain conditions. Let's say the percentage complete is greater than 50. Now, what this means is that only if it is greater than 50, it will send the email. I'm coming back to the vulnerability record. I'm setting it to 44, right? So I'm going to set it to 870 or something. Now this should actually send the email. So this is how we can create the notifications and all. So let's finally see whether a record is created or not. Let me refresh the form again. As the conditions are met, it must be sending the mail, and yes, it has changed from 44 to 70. And after that, an email is triggered. So everything is proper. So this is how we are going to send the emails.

Just make sure that the conditions are set properly. One last thing regarding the notifications is that in the earlier session we discussed things called "events." When an event is triggered, we can basically create the notification. Also, we can actually trigger a notification. When an event is triggered automatically, an email can also be triggered. How can we do that? There is a thing called "Advanced View" over here. If you click on it, you'll see a few extra fields. So it is now asking me when to send. Is it a record inserted, updated, or fired? So if I'm selecting "inserted," "record inserted," or "updated," then you can see these two options. If I select "Event is fired," then the event name is shown. We can select our event name over here. So this is all the information on events available here. Whatever event we want to select If we select, what happens is that if that particular event is triggered automatically, this notification will also be triggered. So this is how we integrate the event and the email notifications.

ServiceNow CSA practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass CSA ServiceNow Certified System Administrator certification exam dumps & practice test questions and answers are to help students.