CSA: ServiceNow Certified System Administrator Certification Video Training Course

CSA: ServiceNow Certified System Administrator certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

General Configurations

3. Access Controls (ACL's)

In our earlier classes, what we have done is, if the requirement is to hide the fields or make the fields read-only, we have used the UI policies. Actually, the UI policies are on the user's side, on the client side, but there are certain things that have to be done based upon the rules. Alternatively, if the user is assigned to a specific group and is a member of that group, he has access to the table. It's not just about one field or two fields, but about the whole table or the whole record. In that case, UI policies cannot be utilized. If it's just a few fields, then it's fine to use the UI policy. But if you're talking about controlling access—the entire access—then we need to take action.

We need to use the ACLs' access controls. First and foremost, for these specific access controls, let's say ACL, we'll be able to see these access controls under system security. This shows all the access controls that are present on all the tables in our current system. But usually we used to see the new button, but right now we are not able to see it, and on top of that, if we open any existing access control record, we cannot modify the table at all. Even the update button is not available. Normally, with the UA policy, if we make the field read-only, the update is visible to us. But it's not the same with this because basically what is happening is that there is an access control that is blocking access to modify this record.

That is the difference between UI policy and access controls. To prevent unauthorised access, we will use ACL to make a field read-only or visible. We use the UI policies, as I'm not able to make any changes over here; basically, I won't even be able to create a new access control for this. A security administrator role, which is higher than an administrator role, exists. We discussed the admin role, which is one of the highest roles, in previous sessions. On top of that, we need and should have a security admin role to create the access controls and all. And even after that, even the current user has it. But even after that, we won't be able to create that because we need to elevate the rules. So click on the user, and then you will see the elevated roles. Just click on that button and make sure that you mark the box, and then click OK, and the form will be reloaded. Now you will be able to see the new button.

So, as you can see, the new button is now visible. And even if I open an existing record, I should be able to modify that record. Yes, I am able to modify them. So this is what the ACL does. Okay? Controlling access at the table and record levels There are two types of ACLs. Before getting into that, let's create an ACL. Let me go back to the list layout and create a new ACL. As we can see, I'm pressing a new button. Now I am able to create a new record. Basically, first we need to understand the four elements listed here. The first one is type. This is simply whether it is on the recorder or whether it is on script, include, or report. So this is not something I am particularly bothered about. We shouldn't be too bothered about it.

Just select the record. The second point to mention is operation. Which operation do you want to control? Is it a create operation, a read operation, a delete operation, or a write operation? Usually, these are the four most frequently used ones. The most common modes of communication are read and write. Let's say, for example, that I'm going to block write access. This is the second thing. Then the third thing is, what are you going to do? What are you going to control? You will have complete control over whatever we are going to discuss over here. So which table do you want to control? It depends on this particular table. Let's select vulnerability management over here, and then there are two different types of ACLs. We'll be talking about it soon. For now, let's say none. which means for the whole table, okay?

Now if I'm blocking access, then that person cannot write the record. This is the third thing. The first thing is the type, which is record. The second thing is operation—write operation, read operation, and all that. So for now, I'm selecting the write operation. The third thing is: what element do you want to control? So far, I've chosen the entire record of a table and who has access to it. Again, this is divided into three parts. For now, let's simplify. Let's add a role. Let's simply say ITIL, and if I click on Save Now, what happens is basically what we are going to do: if an ITL logs into this particular table, he will be able to access the records. He will be able to write the records. If he doesn't have the ITL role, then he won't be able to write the records. Okay? I have controlled based on the rules in the same way that we can control right now.

There are two more things. The first is conditions based on conditions. Also, we can make certain changes, such as not granting access to modify the record if an incident is closed. Once an incident is closed, that's it. No data can be modified. In that case, we can change the state to something like "condition." state is not closed until this condition is met. We will have access if the state is not closed, and then you'll be able to enter the field or enter the record. So this is one thing. Okay, let's start with the role. To get access, he must have the role and that particular record. Must meet the requirement that the state be resolved or created within the last three days of being assigned to the current user. So something like that So based on the current record, we can set the condition.

And the last thing is the script. We have an app option and can get the script if we click on this advanced option. So, if the answer is true, it means the user will have access, which means he will be able to write it. If it is false, then he will not be able to do it. He will not be able to access it. Basically, what exactly do we write? We will write the conditions, like if we can write something like "if the current user is part of XYZteam," then we can write "answer equals to true," or "answer equals to something like this." So this is actually not the exact syntax. I meant the whole syntax is correct except for this first line. Okay, so this is how we are going to modify the ACLs. So, based on these conditions, we can determine whether or not the answer is correct. If this condition is met, it will give access If it is not met, it will not give access. Overall, three things have to return true value; one is the role. If the role is present, it will return true.

If the condition is met, it will return true. If the answer is equal to true, then the script will return true. So that is what it has to do if a user is opening a record: he must and should satisfy all three conditions before he will be able to access that particular record. In this case, in order to access vulnerability records and write vulnerability records, the person must have ITIL access and also meet the requirements of this specific script. For now, let's take a small example. Let's not follow the scripts, and everyone will say: If the caller is, say, not empty, he will be able to change the fields. something like that: let's see if it is not empty, or if it is empty, he can modify it. If it is filled, he will not be able to modify it.

So I have selected the ITL role. The admin guy does have the ITL role, so what we can do is let me impersonate the other users that we have saved, so let's impersonate the ITIL user. What we are attempting to do right now is allow the user to modify the vulnerability record in the caller when it is empty. If the caller is blank, the user should not be able to modify it. So these are the three records that are present. Assume I'm opening one double-zero-one okay, so the caller is already filled. I'm not able to edit any of the fields. I, too, am unable to see the update button. This is what ACL can do. Even you will not be able to update anything. And then, let's say, let's check the other records. Yes, here the colour is empty. So I'm able to edit the field, the table, and this particular record. This is how the ACL works. One thing to note is that in our previous record, what we saw was based on the condition that we were blocking the entire record. We were not able to edit any of the records.

So any field of the record is effectively the update button; this is referred to as table or record level ACL. If we want to block only one particular field or all the fields, then it is called "field level sealing." So that's what we're going to look into now. So I need to reclaim my security role. If you're impersonating any user automatically, your elevated security will be disabled. You need to revivalize your roles. Now I'm able to edit it. So here you can see that it is none, which means I won't even be able to see the update button. But if I want to select a particular field, then it will be like I won't be able to access or won't be able to write anything in that particular field. If I want, I can set the star, which means all the fields, but everything below this star is field level, which means I'll be able to see the update button but I cannot edit the selected field.

But none is at a record level. If I don't have access to the record level, I won't even be able to see the update button. That is the difference. So record level and field level So this is all about the ACL's access controls, giving a brief outline. The only thing we need to remember is type. It is a record operation. We can set what operation you want to control, create, read, write, or delete. Which operation do you want to control, and what do you want to control? Do you want to control the whole record or just certain fields? You can set up the fields, and finally, based on these conditions, you are going to control it. If all three conditions—roles, conditions, and descriptions—match, the individual will be granted access. Even if one particular condition is throwing an error or one person is not allowing one particular condition, then the user won't be able to see it. That's it. Regarding the access controls.

4. SLA, OLA, UC

In this session, we are going to discuss the SLS service level agreements. Before we get into the technical aspects of the service node, we must first understand what SLAs (Service Level Agreements) are. Agreements like this fall under the ITL framework's service-level management section. So, for example, suppose there is a company that provides specific services, such as transportation services. Its service is to pick up the goods from the customer and transport them from the origin to the destination. And it will provide this service under specific contract agreements, which means it will be delivered within, say, 12 hours or 20 hours, depending on their capabilities.

That is how service level agreements are defined. For example, the service will be provided in X amount of time. In the same way, if you are talking about big companies and they are providing certain services, if there is any issue with their service, they will make sure that that particular service will be restored within a certain amount of time. That is nothing but the service-level agreements. If you are talking about incidents, what exactly is an incident? Is there any service disruption?

What is currently happening in that situation is that the company has signed a contract. If there is any interruption, we'll make sure that it will be restored within X amount of time. But how can we calculate in-service now that we have incidents? If an incident is created, we need to attach a timer so that we will know for how much time the incident is open. So that is possible with the SLS in service. Now, simply put, SLS are like timers. It will run whenever we can actually set certain conditions. Based upon the conditions, the timers will run. Once a ticket is created, the timer will start. Once a ticket is resolved, the timer will end. Now we can find out, like, how much time it has taken. The timer will tell how much time it has taken to resolve the incident. So, this is the basic thing about the SLS. Now let's create the SLS. Just type SLA definitions.

So under service level management, you will see the SLA definitions. There are few existing SLAs. Let's create a new one. One thing about SLA is that it can be attached only to the tables that are extending tasks. If you have created a custom table and it is not an extending task, you cannot attach SLA to it. So for now, let's create the SLAs for the incident table. The table's name is "custom P-5," which translates to "priority five." If there is an incident with priority 5, then we are going to trigger an SLA. How long did it take to finalise the contract?

So according to the contract, we have to resolve the issue within, say, one day. If there is a P-5 incident, then it should be resolved within one day. If it is a P-4 incident, which means a bit higher priority, then it should be resolved in less than 24 hours, like something like 22 hours or 20 hours. If it is priority one, it should be resolved within an hour. Something like that Of course, everything depends on the company. Then we can mention the schedule.

As ServiceNow is a cloud-based tool. People from the same instance can access the entire world. The same instance is being used by people in India, and the same instance of the same company will be somewhere in the US. United States. They will be accessing the same instance. However, as you are all aware, time zones differ within each country and from one country to the next. If, let's say, someone from India raises a ticket, and if that particular incident is raised at a time that is outside of the working hours, then what would happen? Should the SLA run? Usually no. If there is an issue at midnight, no one will be there to address it.

So the SLA will not run. Okay, so for that, we need to mention the schedule. What are the SLA's operating hours? What are the working hours of your company that you are going to mention? Over the schedule, we have a certain "out of the box" schedule, which is eight to five weekdays, which means out of all the seven days, only weekdays count as business time, and the other times will not be considered, and the SLA time will not run during those non-business hours.

With the exception of holidays, you can create these schedules by simply typing schedules over the left navigation panel. Under the system scheduler, you'll be able to see it. Yeah, under system scheduler, we can see the schedules. Here, you can create your own schedule. You can define what is a working hour and what is a nonworking hour. Now these are the important things. This is analogous to the start, past, and stop conditions. When should the timer start? Whenever there is a ticket created with these particular conditions, Let's say the state is new, or let's say the state is either new or in progress, and the priority is five, then the time of the SLA will run. Then we have past conditions.

Assume an incident is reported and assigned to a specific team, an executive, and that person attempts to resolve the issue. But meanwhile, he found that he needs certain extra elements, like some extra details from the customer, which will actually be required to resolve the issue. Before getting those details, the person cannot resolve the issue. In that case, what can be done is to put the request on hold, put the incident on hold, and ask for more details from the incident caller. In that case, the SLA should not run.

So for that, this is the place where we can pass the SLA. Whenever an incident is raised, the SLA will be running. However, whenever we set the past conditions, the SLA will be put on hold. So we'll put something like "state E is on hold" here and finally stop condition. It should be something like "state," which is one of either "resolved" or "closed." So that's it. Our SLA is ready now. Let's submit this. Now let's go and create a new incident for us. It will be set simply by filling out the form. As you can see, the priority is five. The state is new. Now, if I save the record at the bottom, I can see the related list. So you can see the task SLA here. And this is the SLA that we have created. custom SLA, and it is in progress.

Now let's say if I'm changing the state to "on hold," you can also see certain "on hold" reasons. A waiting caller is waiting for evidence, problem resolution, or a waiting window. Let's save the record. Now, if we see the SLA, we can see that the state is passed. Earlier, it was in progress. While it is passed, we have mentioned the pass condition in the SLA. Finally, we have the conclusion. If we set it to closed or resort, the SLA will be completed. Before completing that, let's try to understand certain fields over here. Actual elapsed time and actual elapsed percentage So what we can do is bring in some extra fields. business elapsed percentage and business elapsed time. These are actually a bit important.

So let me pull this Let me save it for now. Now you'll see that the whole form will be reloaded, and these two fields will also be added over the list layout. If we look at the SLS, we can see that the actual time is 50 seconds, but the business time is 0 seconds. Basically, what is happening is that this incident is attached to a schedule, and according to that schedule, it is not during business hours. This is not working time. As a result, the business hours are not in effect, but the actual time is. SLA only considers the elapsed time of the business. Okay, so we put "one day"; it will wait for business to be completed within that lapsed time, not the actual time. That is the key thing that we need to understand. And you can see the stage has been crossed once I close. Right? Let me resolve the incident. That's it. The SLA should be completed.

Yes, as you can see, it is completed. So this is how the SLA works. What exactly is an SLA? SLA is an agreement between the customer and the service provider stating that if there is any issue with their service, they will restore it within a certain amount of time. Basically, that is what we have done here. In service now, SLA is nothing but a timer. We are going to set three major and important conditions. What? What is a start condition? What is a pass condition? What is the stop condition? Depending on that, an SLA definition is created. So that's it. Regarding the SLS, before closing it, there is one last thing that is part of the functional training, which is, I would say basically, the SLM service level management. There are actually three types of SLAs. There are three types of service level agreements. One is the service level agreement itself. The second is the operation-level agreement, Ola.

According to service law, the third is the UC underpinning contract. I mean, technically speaking, there is no difference. But if you are talking about functionality, if you're talking about at the company level, then there is a vast difference between SLA, OLA, and UC. SLA is essentially something; all three of these things are agreements that the service will be restored by so-and-so date. Okay? Now, the thing is, who is making the agreement? Depending on that, we have these three different types of SLAs. The service level agreement (SLA) is a contract between the client and the service provider. Ola is the agreement between the teams. The service provider is nothing. But it's like a big company, right? The company has a number of teams.

The agreement between their teams is nothing but an operation-level agreement. And finally, this company will have tie-ups with some other companies to complete their services. Let's say if we are talking about IT companies, they take the laptops and other pieces from other companies. In that case, they are called the vendors. Vendors assist service providers in completing their services. The vendor-service provider contract is nothing more than the UC underpinning contract. Okay? These three are thus only functionally distinct. But if you are talking about ServiceNow, there is a very small difference. When we are creating the SLA definitions, we have the option. This is the one that we have created. So we have the option of selecting what type of SLA it is. So, as you can see, the type is SLA, and if we click on it, we can see the different types: SLA, Ola, and underpinning contract. Based upon the agreement?

The name varies depending on who the agreement is made with. If the agreement is between the service provider and the customer, it is an SLA. If the agreement is between the team members, it is Ola. If the agreement is between the vendor and the service provider, it is the underpinning contract. That's it. We just need to change the type to Ola SLA. That's it. This is what we do in the service now. However, functional people notice a significant difference. So that's it. That's it. Regarding the slate, we can wind it up.

5. Workflow

We've talked about configuration so far, and some of the configuration elements such as business rules, UI actions, and so on. Let's talk about workflows. Now, workflows are, I would simply say, "workflows," or they are actually used to automate multi-step processes.

Let's see what they are and how they can be configured. For that, we need to go to the left navigation pane and search for Workflow Editor. So just type "workflow." And in the left navigation pane, under the application menu Workflow, you will see the Workflow reader. Once you click on it, it will redirect us to a new page. So this is the workflow page. This also has a different user interface. Let's try to understand the UI first. On the top, we have the tabs. First and foremost, let us discuss the subject matter.

This is the place where all the work will be done. This is the major part, the content area, or, actually, it is called the "workflow canvas." And on the right side, we have Palette. In the palette, we have two tabs. One is workflows, and another is the core. Workflows are actually existing workflows. These are all existing workflows. Let's click on any of the workflows. Now we'll be able to see that particular workflow in the Workflow Canvas area. So, for the time being, this is a configured workflow. At the same time, I can also open any other workflow. You can see that there are two different taps created. This is how we can navigate between different workflows at the same time.

This is called the "Workflow" tabs in the pallet. The other thing that we can see is Core. Once we click on it, we'll be able to see all the activities present. These are the primary tasks of Workflow, which is to configure these activities. Whatever you see on this canvas, they are all activities. Let's get started on this discussion and create a workflow for us. You can either click the new plus icon or the new Workflow button. Over here, I'm going to click this plus icon. It will ask us, "What name do you want to give to this particular workflow?" Earlier, if you remember, we created a table called "Service Request," which is actually extending the task table.

So now I'm going to select that table, and the name of the workflow will also be "Service Request." It's up to me. I'm going to name it a service request for now. Now I need to choose which table this workflow will apply to in the table. So that is what we are actually mentioning over here. Here. I'm going to search for the service request. So, after selecting the service request, I can provide any description. Basically, whenever a record is created in this table, this workflow is attached before the record is attached. Do we want to look over any conditions? only if the conditions are met. If you want to attach the workflow, Then you can set the conditions. Right now, I'm going to leave it as is. This is a canvas. These two are activities. All the activities Let's go to the "Core" tab at the top right. So all these activities are actually the things that we configure.

We bring those activities with us. We configure those activities according to our requirements, and then finally, we will map them. Let's say I'm going to submit this for group approval. The next step would be mapping this field and this particular activity. So this is a flow, right? It will go through this and directly end now that it has begun. But I want this to change. So basically, whenever we are at the last end point, we can see this square box. So just drag that thing to any other activity, and that's it.

You can alter your behavior. You have changed the bands. Now I can point from here to there. You can start experimenting with these things. For now, let's keep it as is. Now we're going to check out everything going on here. Some of the key activities we are going to discuss—not all the activities, but the key activities—include: The first thing is the approval group. Basically, let's first discuss the approval user.

This is to trigger any approval for this particular request. If you want to send or request approval after creating a record, you can use this user approval. You can select the user. You can select existing users in service by clicking on the lens icon. Now, this is actually hard coding. Let's say if I'm selecting a person, I can do so in the same way I can select a number of persons. Whatever request is made, it will be sent to all of the people I have chosen. This is actually hard coded, so whatever the request is, these people are fixed. But there might be situations where it could be dynamic.

When a user submits a request, an approval request should be sent to his manager. So a manager will be different for many people, right? So how can we do that dynamic thing that is done through the select fields? So just click on this. You will see all the fields opened by this field in the service request table. Essentially, this field will store the value of or the user record of the person creating the record. Okay, so I'm going to click on this. Plus, here I can see his details. Now I'm going to select his manager. You can see that there is a coded line over here. So this is actually a dynamic thing. What happens is that whenever a request is raised automatically, the approval will be sent to the manager of the open project.

So this is how we can configure the dynamic approvals. And if you want, you can write some scripts. Just click on "Advanced," and you can write the script so that approvals will be added. And one last important thing regarding the approvals is: if we have, let's say, ten approvals, should one approval be sufficient? Or everyone's approval is required? Or only the first person's response is required? What exactly do we want? So based upon that, we can actually select these three things. If you want to set something based on the script, then you can use the last option. We can give this a name: manager approval. So that's it. The activity has been created. Now we can drag the branch over here.

Now we can see that the flow has been modified. The same thing goes for the approval group. Here we are actually selecting a user. However, we can separate the groups here. There are actually no important things over here. Approval action is just like a field. We can specify whether approval is requested, rejected, or approved.

So this is usually used when we are in the task fields. I'm referring to the task records. Let's say I'm using this for this; let's go to the original service request table. Then we'll get to understand this approval action. And here I am searching for the service request. Now I'm going to bring in a field over the form layout. So you can see that there are four different options. Rejected, approved, requested, or not yet requested Let's go to the workflow editor. Make sure that you remember these choices. Now let's go to the workflow editor. The approval action can be seen here.

Now, if we see action, mark the task as approved. Mark Task has rejected Mark's tasks as requested. So, if I select "approved," the approval field will be set to "approve." If I select Mark task as rejected, the task's approval field will be rejected. Right now, Task is nothing more than a service request. So that is how we can use the approval action. Usually, what people do is mark it as approved. If this is approved, it will be moved to this. If it is rejected, we can create another approval action. And there we can set the approval to "rejected." And the branch goes like this: And then let's see the conditions. So this is one of the important things that we need to pretty much remember. First, if the condition is met, we have two options.

One is based upon the fields, and another is based upon some script. So first, let's see the script and the fields directly. Assume priority is one and give the name P one. Let's say the processes If the request is of priority 1, then there should be no approval. It should automatically skip the approval and move ahead. Okay. If it is not, then it should go for approval.

So to mention these conditions, we can use the if clause. At the bottom, we can see a thing called "advanced," where we can write certain scripts. Here is an object called an answer. If the answer is yes, then it will go with the yes root or S branch. If the answer is no, then it will go through the no branch. And then we have Switch. In our earlier example, we saw that there were two choices. It either goes yes or it goes no. What if there are more choices?

Assume we have a category on the internet form. If the record belongs to category A, it should be approved by a category of category B, and then it should be approved by group B. So if it is depending on that, if the branches are depending on the categories, then you can set the switch. For now, let's select any of the fields that have a choice field.

Let's take, for example, the state field. What happens is that it creates the branches automatically based upon the choices. If you remember the choices, the state choices are: pending, open, work in progress, and if the state is pending, it will go in this direction. If it is open, then it will go in a different direction. If it is in progress, it will go in any direction, so this is how you can set the switch, and then we have to wait for the condition. This is also a bit similar to the if condition.

But the point is, let's say for example, if I'm setting a condition like "state is in progress" or "work is in progress" and I wait until work is in progress, what happens is basically that if the flow is, let's say, like this, once it reaches this "wait for condition," it will wait until the condition mentioned in the particular activity is true. Until it is true, it will not move ahead. It will just wait for the same activity. Either you can use the conditions or you can use the script: if the answer is equal to true, then the flow workflow will move ahead; if not, if the answer is false, then the workflow will not move ahead; that's the wait for condition. Those are the important things related to the conditions coming with the notifications.

We have already seen how to create a notification, but this is something a bit different because we are actually triggering it from the workflow. But basic things are always the same. We can add the subject, we can add the message, and we can bring the field values from here. And then to whom should this particular email be sent to?recipients so that we can reuse this list You can select the people who will receive it, or you can select the group, or you can write some script. This is how we can send a notification from the workflow, and in our earlier session we have also talked about the events.

How do I create an event? We can go to the registry and create an event, but how do we trigger it? We can write a simple line called "JS event queue" to trigger the event in the workflow. If you want to trigger an event, you can use this activity. You can select the activity that you want to trigger. You will be able to see all the events in this particular window; there are 470.

You can select any of the events. So what happens is that once the flow touches this activity, this event will be triggered. You can also set the parameters paramone and paramtwo in the service catalog, but we won't go over that right now because it's not a very common thing to do. For tasks, we can create a record in the incident table or any table that is related to the task. Basically, any table that is a child of the task table, such as incident, is a task child. Problem solving is a difficult task as well. Even our service request is a child on the task table.

So we can select any of the task child tasks that will be created, and we can also set certain field values. What is the priority of that task created? And you can also wait until the task is completed. If we check this option, the workflow will not move ahead until this task is closed. If it is closed, only then will it move ahead. While creating the task, we can also set the fields like fulfilment group or assignment group assigned to the short description instructions. These are all fields on the task table. So once you fill this in automatically, the newly created task will contain these values. You can also write a script if you click on this advance.

You can write a script like "task field name equal to the value which you want to set." So this is how you are going to create a task, and then we have a timer. This is basically to hold the workflow for a certain time. You can see that it is asking for a duration, like days, hours, and all. If I mention something like 5 hours, then whenever the activity is triggered at this particular activity, the workflow will wait for 5 hours or whatever.

The time we are going to mention it will be dependent on that. If we want certain relative things, then we can go for relative durations, wherein it will be like two days, two business days, so all these things you can do with the relative duration, or else you can go with the fields. The current service request In the current service request table, we have many fields in those fields. If you have any duration-related things, then you can use those fields. Then finally, utilities. The important things over here are, I would say, branch and join. They are not important, but it is good to understand them.

Then log the message, return the value, run the script, and set the values. Branch So, for example, we could do something similar to this and this. So from one endpoint, we are taking two branches. So, according to the service now, it is not the best practice. We should start by making a branch. There is nothing to configure in this branch. We are just giving it a name, like "branch," and then we are redirecting it to here, and from the branch we are going to call the "approval" and also the "end," and we'll remove these two. So the main point is that we should not send two branches from our normal activities. That is what this particular branch specifies. then we have joined.

This is just like a reciprocal favor. That earlier. It's as if we've arrived at a dead end. We're going to bring in many branches now; from many branches, we're going to bring to this particular join; let's say you're going to the join and approving it from yes. Also, you're going to join. So directly. What you can do is send the transactions directly to the end directly. So this is what we can do. So directly, we can send it to a particular activity.

However, the best practise is to avoid doing so and instead go to the join. You can also take the complete and set it to end from the join. So this is what we can do. This is the join activity, then we have logmessage, and we can actually log messages. In essence, there is a table called the Sys underscore log, and whatever we type here will be saved in that table for future reference. If you want to test, like, what exactly is happening, you can put in the log messages, and then we have set values.

There will be situations wherein, just before ending the workflow, you might need to set certain values like state to complete, closed, complete, and also active to false. So this is how you can use set state and active. This is one of the options. Otherwise, you can use the runscript to write scripts. This run script is purely server-side, so you can use the GS object and also the current object. You can do all the server-side scripting over here. So that's it.

This is the basic situation regarding the workflow. We will not test the workflow right now because we will have a purely hands-on session in which we will basically create a new application and a small workflow. So that's it. In terms of the workflow, simply put, what is the workflow? Through the workflows, we are going to execute multiple processes or multiple steps in just one process.

Prepaway's CSA: ServiceNow Certified System Administrator video training course for passing certification exams is the only solution which you need.