1. Update Sets
Welcome back. Now we are going to discuss the update sets. Typically, there will be three distinct instances in a ServiceNow project. The first instance will be for developers, followed by test instances, and finally by production instances. The process. Typically, the process would be for the people to develop all of their configuration services in the developer instance, and then move the data once they were finished. They migrate their configuration from the development instance to the test instance, and then from the development instance to their test instance, they will ask the users or clients to confirm that everything is working properly.
And then finally, from the test instance, they move the configuration to production. This is how the configuration is moved from one instance to another instance.
But how exactly is this transfer taking place? That is done by the update sets in the left navigation pan type update sets. So under system update sets, you can see the application menu. navigate to the local update sets This update sets This table is a table that contains the update sets. Actually, whenever we capture any details, whenever we save any details, any configurations, whether it’s business rules or client scripts or creating dictionary items or tables, all of that will be captured in one of these updates. Now let me create an update set. First, let’s call this capture configuration.
Let me put the state as “in progress.” If I want, I can add some descriptions; once I’m done with that, I need to click on “Save.” Now if I go to the settings over the top, I can see an extra tab called “developer” for us, and here, if you see, there is an update set if we want. What we can do is select the update set. In our case, it is capture configurations. There is a pop-up. Now, what we’ll do is go ahead and create or modify some business rules. Business rules. I am going to change its name of it.I am just putting a dot, or let me put in an underscore.
Now, I’m coming back to the update sets. If I go to the capture configurations, you can see that the business rule is captured in the customer updates. Whatever we do, whatever configuration is modified, everything should be captured in an update set. How to change the update set Right now, as you can see, I am capturing configurations?
If I want, I can create new updates and capture the configurations over that particular update set, but at any point in time, you must and should select an update set. It should either be a default or an update set created by the ServiceNow system. In our earlier classes, we created a lot of configurations, like table creations, dictionary entries, business rules, and client scripts. All those things will be captured in the update set. The default update is the one that we have created. The SLA definitions If I click on the created time, you can see all the changes that we have made captured over here in the grid canvas dashboards. If we continue, these are all of the updates that we or the customer have made in Service Now.
So, for a small example, what we can do is go to another client script and modify a client script. So before we modify that, let’s change the update setting. Let’s keep it default. Now, if I try to modify, let’s say, this one, let’s deactivate this particular client script. Now, if I go to the update set, it must have captured this particular update. If I go to the customer updates, yes, it did capture it. Maybe we haven’t captured it properly. The earlier client script, which we did not modify properly, So this is basically how all the configurations will be captured in the update sets. One of the important questions regarding the ITIL, sorry, admin certification for Service Now is: What data is not captured in an update set?
Transactional data is never captured. Transactional data is nothing but incident records, change records, and problem records—all of which the ITIL people or end users work upon. But only the configurations will be captured in the update sets. not the data, only the configurations. So this is how we create an update set, select that particular update set, and capture the data. Let’s say, for example, that as soon as my configurations are done, what I am going to do is move this update set to another instance. For that, I must make sure that the state is in a complete state. So I’m saving the record. If you notice a new related link labelled “export to XML,” click on it. Now I suddenly remember that I forgot to capture one more element in the configuration in this update set.
Then, if I try to go to the update sets, I will not be able to see the update set because its current state is complete. Only if the state is in progress will we be able to select the update set and capture the data. If you want to make it again, you can just make it in progress and save the record. Just make sure that the update is in progress, then save the record. Then you will be able to access the update set here. However, it is best practice not to reopen an update that has already been closed. So for that, the other option is to create a new update set. Let’s call it missing configuration. I can submit it right now and then come over here and choose it. Otherwise, I can simply click on this submission and it will be updated automatically. The update set will be that particular update set, which will become my current update set.
Now, if I make any changes, let’s say I go to UI actions and change this list action to “let me make the active field false.” Now, if I go to the update set, I can see that particular configuration has been captured. What I can do is go back to the UI, update sets, or local update sets. I can see two update sets are present now. capture configurations and missing configurations. Now, one particular element, one particular configuration, is in this update set, and another is in this update set. What I can do is simply match these updates, so I can give it a name, let it be a matched update set, and I only need to select these two. So I need to filter out the default whatever is present over here. If I click on “match all the updates,” customer updates will be moved to one single update set. So that’s it. If I go to the meshed update set, I will be able to see two customer updates: the UI action and the business rule.
So this is how we match an update set. We can match two updates at once, or you can match N updates at once. Now, let’s put this update set in a complete state, and then what we can do is export this in the form of XML, and then we can import this XML into any other instance. For now, I have taken a new instance wherein we can import this XML. I will keep these two instances side by side so that you guys can understand. The left one is the one on which we have worked, and this is another different instance. What I’m going to do is let me go to the update sets.
As you can see, there are no other updates in the local update sets; only default is present. If I go to our update sets, we have four updates. Now, I’m going to the mesh update setting and I’m going to export the XML. clicking on “Export the XML.” You can see the XML is saved. Now I’m going to the retrieved update set over the destination instance, and I’m clicking on Import updates. I should go with XML here. XML? I have selected that, and I’m uploading it now. So this is the measure update set from this instance that we saw earlier.
As you can see if you scroll down, we have customer updates. There are two updates. The first is a business rule, and the second is a UI action. If I click on preview, then I can commit this particular update set. So once I click on this commit update set, what happens is that particular configuration will be saved. In this case, the new instance is on the left side, the left instance, and it can simply be compared to a development instance. We do the work in the update sets. We capture everything in the update set, we export the XML, and here we go to the retriever update set. We import the XML, then preview it before committing the update set. So this is what we do to transfer the configuration from one instance to another instance. This is actually a bit of a manual process. The other way is by creating an update source.
So we have a thing called update sources. When you click on update sources, we can create a new remote instance and provide the URL of the instance, as well as the username and password. So let me give certain details; for now, here, basically, I must be giving the URL of the instance. So let me provide all the details and save the record.
So this is how we add the URL, then the admin user ID, and then the password. Over here, we must and should provide an administer ID and password. When we’re finished, we should click on the retrieved completed update sets. Let’s click on it and see what happens. We can see that there is a pop-up that says “no update retrieved,” which means that no updates were retrieved because they already existed. Basically, what we have done is export that XML and import it into our new instance; because of that, what is going to happen? It is matching it, so it is not going to load that. Let’s do one thing. Let’s go and delete that record, and let’s come back to this place again. I’m going to the update sets now to retrieve updates. I am deleting this update set now. Now I’m going to check the update sources; we’ll see what happens. We’ll go to the update set and pull this. Let’s see how it works.
So, for example, you can see that one record was retrieved. As we can see, it has come. So this is how we usually do it. We will create the update source and then get it back to this. We create the update source, we retrieve the update sets, and automatically all those updates will come to all the completed update sets. That thing is very important because, as we can see if we go to the local update sheets, there are four updates. But, if you only saw one update, why didn’t all four arrive? The question is what condition they are in. Only the completed update sheets will be copied to the new instance. So that is the point. Make sure that you are closing your update sheets when you want the update sheet to be moved to another instance. So once we get the retrieved updates, the steps are the same again. Just open the update set, preview it, and then finally commit it. That’s it. So this is the update that updates its process.
2. Plugins
Till now, we have seen certain applications that are available out of the box, like Incident and Problem Change. We did not actually create any orthosis tables like Incident Problem at all, but they have come out of the box. Basically, those are certain configurations that are provided by the service. Now, on top of it, there are many applications like service test calls or PPM. project portfolio management. So there are many applications that Service Now provides out of the box. But by default, all these applications are not enabled. Only the basic ITSM modules like Incident, Problem Change, and some others are all enabled. The plugins are how we can enable them. Just type plugins in the left navigation pane. You will see this under the system definition. Then you can see all the plugins. Basically, in our last session, we discussed the update sets. What exactly is an update set? It captures the data. It stores configuration null data and configuration data in a single file.
So plugging in is also the same. Assume there is such a thing as a Call Service Desk Call. This is yet another incident problem change that is application-like. This is also another application. If we want to activate it, we can just click on this activate button. Let’s see what happens. Yes, it is totally activated. Now I’m going to reload the form. Now you can see there are certain plugin files. These are all configuration data such as access controls, tables, access rules, business rules, list business rules, field labels, dictionaries, and so on. These are all configurational data, which we have already discussed. Okay, what exactly is happening? Basically, plugging in is nothing. However, we can think of that as an update set. It has all the data related to certain applications. It could be a small application, a large application, or specific integrations. So a plug-in is just like an update set, and it has certain data. Now, if we see in the left navigation pane, if we type “service,” you can see this application called callers Incident; this application was not created by default. Okay? Earlier, this was not available to the callers, the new call, or these applications; these tables are actually not available to all as I have enabled this. These tables have come in. So, this is the table that I am talking about, the new call table. If you click on it, it will redirect us to the new call table.
So this is created by the plugin. This is what the plug-in is. We can activate certain plugins so that we can add extra features to our ServiceNow instance. Certain Service Now plugins are free. There are some paid plugins available as well. Let’s say, for example, if you are talking about integrations like orchestration or discovery, those are all related to certain integrations, and basically, they are paid plugins. We can create them and enable them in our developer instance. We can test it as long as you are not using it for commercial purposes. You can use the Service Now instance for testing purposes. But if you are using the real instance, then it is a paid plugin. Service Now, on the other hand, will tell you whether a plugin is paid or free. If you really have the commercial version of the ServiceNow instance, as I said, we are using the developer instances. It’s fine; you can use all of the plugins without issue. So that’s it.
