1. Catalog Items
Hello. Welcome back. In this video, we are going to discuss service catalogs. In our earlier sessions, we have discussed incidents and problems. Basically, whenever there is an issue, users will raise either incidents or problems. But what if they want something? What if they want to raise requests to have access to a particular application? They want to create new IDs for them, or they want a new laptop, or they want a new server created. In those cases, they do not raise incidents or problems. Instead, they will be raising service catalogue items. Service Catalog Request Let us begin by impersonating an end user and walking through the process. We will impersonate Joey, an employee who is an end-user and doesn’t have any role in the system. as he is an end user. He just has access to three applications. One is self-service, password reset, and collaboration.
Under self-service, he can see the service catalog. The service catalogs It’s just like a shopping cart. Online shopping cart Once I see this homepage service catalogue, I can have access to all the different categories. Usually, in our online shopping or any other shopping, we have different categories like apparel, home decor, or electronics. in the same way. In this catalog, there are eight categories: services, hardware, software, and so on. Let’s say this person, Joey, wants a new laptop that would fall under hardware. Let’s go with Laptop or MacBook Pro. And, as you can see, the price is visible. I can also add this to my shopping cart. Then I’ll be able to go shopping again. I do have access to the catalogue again, so I can add another item. Let’s say desktops. I’m going to select executor on the desktop here.
While submitting the request, I do have access to give certain specifications for this—memory, hard drive, all these things. I’ll add this particular item to my Cart, add to Cart. And finally, I will click on “Proceed to Check out.” So that’s it. Now Joey, the employee, has submitted two requests. The first is a PC (Dell Precision), and the second is a MacBook Pro. This guy, Joey, wants two things, and he has requested them. If there is only one request, two requested items are created beneath it. Let’s understand them before impersonating ITIL. Let’s see how this person can see his own requested item. The requested item number is displayed at the top. This is the only information the end user can see: what the catalogue item is about, the current stage, and the approval status. That’s it. Now let us impersonate an ITIL user. These are the people who work on These Are R ATMs.
The requested items are nothing but rhythms for him. There is a new application menu called Service Catalog. And underneath the service catalog, he can go to the items. As you can see, he has raised two RATMS. One is the executive desktop, and another is the MacBook Pro. These are the two RATMS. If I go to the request, I can see the latest one, which was created by Joe. If I open the request, I can see some extra details about this request. For the total price of this request, I have selected two elements, or two RATMS. So it has calculated the total price and shown it over here. Now, under the related list, we can see the requested items. If a user submits ten requested items in one go, then one request will be created and ten requested items will be created. So that is the request. Now let’s get into the requested item. Let’s say a developer laptop MacBook: Now this is the requested item—the item that was raised by the requester.
Who is this request for a due date for a configuration item, and what is its status? Only ITIL personnel have access to these details. And also, if he has selected anything over on the initial page while submitting the request, he will be able to see those things. Also, he can add some additional comments so that those will be communicated with the customer. At the bottom, I can see catalogue tasks. I can create catalogue tasks, but the requested item is not yet approved. The request is not yet approved. So maybe we can attach a workflow to this catalogue item so that once a request is raised, we can trigger approvals for this RATM and also tasks. We can automatically create catalogue tasks. Also, as you can see, there are three important tables when we are talking about catalogue items. Service catalogue requests One is the request, and another is items. Items are nothing but requested items, or RATMS. If a user is submitting ten catalogue items in one go, then one request and ten RATMS will be created, and each RITM can have different tasks. That is actually task cataloging. That’s it. This is the procedure that the end users follow. Let’s take a look at the admin’s perspective and see what an admin can do regarding the catalogue items. If we type “service catalog” on the left navigation pane, we can see many more modules.
ITIL was able to see very few modules, but the administrator can see many more modules. Earlier, the ITL was able to see only these modules. These are visible to Admin. Also, the main things that we need to remember are to maintain catalogs, maintain categories, and maintain items. Let’s look at what catalogues are. In our earlier example, we opened the service catalog, and in that service catalog, as I said, there were many categories. If I open the service catalog, I can see all the categories. Over here, there are 35 characters right now, some of whom are parents. Okay? Now the point is that there are 151 catalogue items, and these catalogue items are categorised under 35 different categories. On top of it, the higher level is the catalog. The categories have something on their tops, which is this catalog, and the categories also contain the catalogue items. So catalogue is the highest level, then categories, and then catalogue items. If we come back to the catalogues, we can see the technical catalog.
All the RATMS related to this now come under the Service Catalog. All the catalogue items that are production services go to the IT department. They are listed in the technical catalog. There are certain organisations that have a different catalogue for financial elements, just as HR-related catalogue items come under the Finance Catalog. So this is how people or organisations define catalogs. How do I create a catalog? Just go to the maintenance catalogues and click on “New.” You’ll be able to create the catalogue if you go to the maintenance categories. I can see all the categories already existing in the system. If I go and click on “Create New,” I’ll be able to create a new catalog and a new category. So I can mention something like testing. I can keep this category under any of the catalogs. Let’s say a service catalog. and I can submit. I can fill in the basic information over here. If I sort by then, I’ll be able to see the category at the top. Now let’s go to the maintenance items. This is where we define the catalogue items. We can see all the existing catalogue items over here. There are 153 catalogue items available right now.
Let’s create a new catalogue for us. Now let’s say we want a catalogue item for getting a new server created. The user raised this catalogue item so that they could have a new server. So in that case, let’s say the catalogue item name is New Server. Should this be available only on the desktop application or on mobile? Also, I can set certain pricing elements over here, in the catalog. Let’s say I’m going to select ServiceCatalog, and I can select the category. Let us put our newly developed testing to the test. I can attach a workflow for this catalogue item, and there is a default execution plan. We will see exactly what it is soon. Let’s include a brief description in the NewServer request, followed by a more detailed description. Raise this request to get a new server created. I’m going to save the catalogue item for later. Now, if we scroll down, we can see catalogue variables in this catalogue item form. What exactly are these variables? If you remember when we were raising the MacBook request or the Dell Precision request, we were actually being asked certain questions like, “What is the memory?” What is the ram? All these parts So there are only these variables. Let’s create a new variable.
As you can see, this is the variable form. Variables can be thought of as fields in their own right. But these are specific catalogue items. Over the form, we have fields such as Incident Form and Problem Form, a short description field, and reference fields such as Users and All, as well as an Assignment Group field. Those are fields on the usual tables. But these variables are specific to the catalogue items; they also have different types, like in the fields, where we have references and strings, all in the same way. We have a reference here, but no string directly. But you can have single-line text or multi-line text; as you can see, single-line text will have a striped line, but multi-line text will have multiple lines. Like, say, for example, this is a single-line text and this is a multiline text. Names would differ when you compare the fields with the usual table fields. But whatever you see over there, at least all of them will be available over here: all the important things and all the important types. There was a split beginning, a split ending, and a split everything. Here we have containers. Let’s say I need something called a “multiple choice” or, let’s say, a “multiple choice.” Now we’ll go for the question: what is the question?
I need to ask something from the user, like what type of server you want. So for that, let’s say server type and server underscoretype question are what users see, and name is what is internally stored; if we are writing scripts, we need to write the scripts on something And, because I have chosen choice direction down or across, there are some attributes that you can investigate that are very similar to the fields. Now let’s go to the choices. The first choice is Linux, and then let’s add one more choice. Windows now has two choices. Let’s go to the form by going to the catalog. In this catalog, we can see the variable created at the bottom, and there is one more variable that I would like to show, and this is a list corrector. This works a bit like the usual list type in the fields where you can select multiple reference records, but the way you select is different. Let’s say I’m going to select the user table, and the question would be approvals. Now let’s submit the request. Let’s give it a shot and see what happens.
This is the list collector. You can select all the users or any user you want to have the approval sent to. If you scroll down, you can see the field in which we have created the server type: Linux or Windows. So this is how we create the variables and create the catalogue items. As you can see under the “Service Catalog” section of the “Testing” category, we have created a new server and a new server request. This is the short description, and this is the description. Once we submit the request, it will be sent. The request will be submitted, and if there is any workflow attached accordingly, it will be processed in the next few sessions.
We’ll be creating a small workflow for this, but before that, let’s try to understand a few more things regarding the catalogue items. At the bottom, there is a new thing called variable sets. Let me add a variable set here. It says standard employee questions, and if we scroll down again, I’ll be able to see the variable set here. Now I’m going to try this catalogue item. You can see approvals, then server type, and then two extra fields have come.Who is this request for, and when do you need this? These two variables are derived from the variable set. Let me go back to the configure item, which is a catalogue item. If we scroll down, we can see the variable set. Under this variable set, we can see there are two variables. Basically, what exactly is a variable set? A variable set is a container, or as you can see, a collection of variables.
You can create generic variables under one variableset, and you can add that variable set to any number of catalogue items. So the chances and the efforts to be put into creating variables for all the tables and all the catalogue items will be reduced. So you create a variable set that is actually reusable, and you use that particular variable set for all the required catalogue items. This is actually a standard employee question. So, for all of the RATMS for all of the catalogue items, we may need these two pieces of information: who is requesting and when do you need this? You can have these two variables on all catalogue items by either manually creating the variables or adding the variable set you created to the catalogue item. There is one more thing called “availability for.” This is where user criteria come into play. Let’s say, for example, that this catalogue item has to be restricted to certain conditions, like if the user is from so-and-so company, or if the user is from so-and-so location, or if the user is from so-and-so department, only then can he see it. Let’s go ahead and create a variable. Sorry, user criteria We can see it is asking for a name, and we can define the user criteria based on these six things.
We can limit access to the catalogue item to only these users, groups, or roles. Or, as discussed earlier, with these conditions, we can create a user criteria and reuse it in any of the catalogue items again and again. Now I’m going to use auser criteria that are already in place. Let’s say North American employees If I scroll down again and go to the user criteria, I can see that this particular user criteria belongs to a particular company. which means if a user is from this company only, then the catalogue item, the new server catalogue item, will be available for him. If he is not from that company, he cannot see this catalogue item. So that is what the user criteria are all about. On top of this, this is actually a bit similar to the usual fields. like we have catalogue client scripts and catalogue UI policies. On the usual tables, we have UI policies and client scripts. What do they do? The same thing will be done by these two catalogue elements, like catalogue UI policies and catalogue client scripts. The only difference is during Usually, when we are talking about tables, we select the table on which the client script should work. But here we select the catalogue item on which this should work. And whatever we write over here, if you are trying to get any variable or any field, we are basically actually querying the variables on the tables.
We write the scripts based on the fields. However, we write the scriptson variables that we just created on these catalogue items. The types are again the same on change, on submit, and on load; they won’t be on sale or edit. But these are the three catalogue client scripts. If I am going to select on change, it will ask me which variable is on change of which variable, so I can see all the two variables and also the variables from the variable set. The same thing goes with the UI policies. You will also be creating UI policies for the variables. For example, if the server type is Linux, then display so and so fields. Or if the server type is Windows, then show some other fields, hide a field, or maybe make a field read-only or make a field mandatory. The theoretical part, all the things related to these two, are the same. The only difference is that we’re writing them on variables, these catalogue variables. So that’s it. Regarding the catalogue items, in the next session we are going to discuss a new thing called record producers, which is actually a bit related to the catalogue items. So let’s see what they are.
2. Record Producer
in a service. Now, there might be situations where end users do not have access to certain tables, like change requests, so on and so forth, but they want to raise a change request even though they don’t have access to create a new record in a table. We want to provide a special place or option for directly creating a record, which is where record producers come in. Let’s say I’m going to impersonate an end user for now. As you can see, his main way of accessing things is through the self-service module and self-service application menu. Here he has the option to see all his incidents. Now, this is the layout of the instant list. He can click on “create this new button,” but as you can see, the form is different. Basically, he is not allowed to create a record directly. However, we are providing him with an opportunity and another way to create this incident request. In the same way, we can also give them access to create change requests.
End users should not usually work on change requests, but they should be able to create change requests so that other people can work on them. How can we do that? Through record producers. The name itself—with the name itself, you can understand it creates a record. produces a record. It’s nothing but creating a record. Right now, this is related to an incident. Say, for example, if I am setting the agency to high and this is a test for record producers, and if I submit, I make a note that we are not able to see any catalogue shopping carts, and all over here, I’m going to submit it. So here is the incident, there is an incident number, and here is a short description. So this is how he can create a new incident. There is no other way for the incident to be created by the end users. Usually what happens is they can go to the service catalog, and in the service catalog, he can search for something called “create an incident.” This is not a catalogue item, but it is a record producer. The form is a bit different because on the right side we are not able to see any shopping carts. Typically, if it is a catalogue item, the shopping cart will be visible in the record producers.
We will not be able to if we submit this request automatically, which creates a recording incident and then lets the process go ahead. Whatever the process is for the incident or the change, it will go ahead. Let’s create these record producers. For our example, we are going to create a record producer for change requests. How can we create record producers? Just type “record producers” in the left navigation pane, and you’ll be able to find it under “service catalog” so you can see record producers. These are the existing record producers. If I try to create a new one, it asks for a name. Who is the record producer’s name? Here’s another change request. Where should the record be created? Once the user submits, where should that record be created? I am going to select “Change Request,” then “Short Description,” and “Description.” This is a short description, and you can see the redirect to generate a task record or catalogue homepage. Once the user submits the request, should he be redirected to the record created or should he be redirected to the catalogue homepage?
We can write some scripts. Allow me to submit this request as well as this record producer. This record producer has variables, variable sets, categories, catalogues available for catalogue UI policies, and catalogue line scripts. All of these are the topics we discussed on the catalogue items. Everything is the same; there is no difference at all. Whatever variables we are going to create over here, these UA policies and catalogue client scripts will work on these variables. The definition of the variable sets remains the same. The category catalogues remain unchanged and are accessible to all users. And this is just the negation of that user criteria. Those people will be unable to see if I choose a user criteria over here. If I select a user criteria over here, those people can see the request, so I can see this record’s producers This option is not available for catalogue items. Let’s go ahead and create a new variable. I’m just creating two fields. Let’s say one is short description and the other is short description. Let’s say short.
This will be one line of text. You can see the variables again; all the things are the same. The types are all the same. The only thing is that we can see a new field called Map a Field. Let me select this field. What happens is that I choose a change request. Once the user submits the request, this record producer has this particular question: where should this be stored on the change request? There are a number of fields. In which field should this value be stored? that we can do over here. I’m going to choose the short description here. Once the user submits automatically, the details entered over here will be copied to the short description of the change request created. I can make it mandatory if I want and then submit. Let’s say I’m going to have another variable. Let me call it a description, and let me call this the DSC. I’m not going to map the field directly. Instead, let me have multiline text; remember the name DSC in the script. I can use something like “current description equals producer DSC.” What this does is nothing but make the change request object current. If I want to have the description field, I can write like this: If I want to have a short description field, I can write “current short underscore description.”
If I want to have a priority field, I can write about current priorities. As a result, you can map the field in the record producer in this manner. We may need to write some extra code. But for now, as for the testing, I’m just writing this code; let’s see how it works. I’m going to try it. You can see the record producer’s short description and description. this field test. And let us refer to this text as Short descriptions can be found in the list, and descriptions can be found in the text. So this is how you map the record producer’s fields. Why do we use record producers? It is used to create records directly. Usually, if we are talking about catalogue items, we create R ATMs. Before that, our request will be created, and underneath the R ATMs, we have catalogue tasks. So, instead of all of this, if we want a record created in a usable format right away, we can use record producers functionally. When do we use record producers? This is typically very useful for end users who do not have access to a specific table. But they should be able to submit tickets and submit the creation of those new records, but they won’t be able to access those records or work on those records. So this is how we use record producers, and this is how we actually create record producers.
3. Order Guide
Another topic that is required to be covered in the catalogues is the order guide. The order guide is basically a grouping of catalogue items. Let’s say, for example, that if a new employee is going to join an organization, there might be certain catalogue requests that are to be submitted. submitted like there will be a catalogue item to create a new employee ID for him. There will be a new catalogue item for creating email IDs, another for disc drop requests, and possibly another for something access-related. Okay, whenever a new hire is going to join the organization, there might be a certain number of catalogue items that are to be submitted.
Usually, what the users can do is what the IT people can do: they can come to the service catalog and create catalogue items. Actually, they can go to each and every catalogue item. They can fill out the form, and they can add to the court. And again, they should go back to another catalogue item, fill out the form, and then add it to the court. Likewise, they should go to all the catalogue items and finally submit the request, so that one request will be created and a number of R ATMs will be created. This is what most people can do. But there are chances that people might forget to submit certain catalogue items. What can be done in those situations? That is where order guides come into play. Let’s see order guides. Under catalogue definitions, we can see order guides. Let’s go to this existing order guide for new hires. Again, this order guide is very similar to catalogue items. We can see catalogs, the catalogue name under which it has to come, and then the category can give it an icon, then a short description and a description.
Finally, at the bottom, I have variables. I can also get variables set. I can right-click, configure related lists, and come back here. I can bring the variable sets up so we can see the variables, variable sets, categories, and catalogues available for and not available for. These are all the same as those we have discussed earlier. Runbase is the one that is a bit new, and we are going to discuss it soon. Let’s say I am going to click on “Try it.” I can see the image and then the description. The view is a bit different. As you can see, there is no option for me to see the cart right now. Initially, on the form, I can see certain variables. These are the variables that we have created over the course of the order guide. I can provide certain details. Will your employee need anything nonstandard right now that I have selected it? No. The next step is to select options. You can see the flow over here on the top, depending upon the variable selected. On the first list of needs, I can see five catalogue items. This is one catalogue item.
I can enter the data I want and see how much it will cost. If I go to the next catalogue item, I can see this particular catalogue item’s details. There are no questions, and there are no variables on this particular catalogue item. If I go to a new email account, I have a variable over here. I must and should fill this out, then copy the VPN desktop setup. So let me come back to the description of needs. Again, just try to remember the standard laptop, external monitor, new email account, corp, VPN, and desk setup. I’m returning now to describe requirements. Let’s say I’m going to select—will your employee need anything nonstandard? Yes, this is again a catalogue of UI policies. If yes, display specific fields. If it is not, do not show those fields. What device type? Consider the developer mobile device type. I’m going to choose iPhone now, and as you can see, there’s another catalogue item called iPhone 6. What we understand is that depending on the description’s need for variable values, the number of catalogue items we see will differ.
Finally, if I check out, let me fill in this mandatory field, and then if I checkout, there are six catalogue items right now. Sorry. Six catalogue items have been submitted, so far. Okay, I’m going to check out. As you can see, one request is created, along with 1234 ritms and two more ritms. This is a monthly charge that is included. This has annual charges included, and the top one has no charges. So that is the reason they are in different locations. If I go to the request, I can see all the RATMS underneath. There are six rites. This is the usual process that occurs. Like requests, request items are also created. If I go to the requested item, I can see the tasks, and people fulfil those tasks. Finally, the RATMS are closed, and automatically, the requests are closed. This is business as usual, with the exception of order guides. We are going to write a rule base where we define at what particular time which particular catalogue items should be shown. There are nine rule bases. If I open this, or if I open the iPhone 6, this one.
If you see this guide, This is an ordering guide for new employees. If in this order guide there is a variable called “mobile device type,” and if it is “iPhone,” then include this catalogue item. This is how we define the rule base. Depending on the catalogue variable conditions, all of the rule bases are the same. We are going to show you the catalogue items. Okay, all these are the same. So yeah, that’s it. Regarding the order guides, an order guide is basically a simple thing. This is used to group certain catalogue items based on their functionality. Obviously, if the user is a new employee who is going to join the company, then there are certain catalogue items that are required. So we are going to group them. We are going to first create variables called initial variables, and in the rule base we are going to define based on those variables which catalogue items should be shown. We can also remove the conditions so that all the time, whatever the variables are selected, those catalogue items are shown.
The cascade variables are a final important question that is frequently asked during interviews and administrator certification. What are the cascade variables? We’ve allowed me to go up. We have variables, and we have variable names. And the question is, what do we see and name internally as HiringManager, Hiring Group, Remote Corp Office, and so on? We may have a variable in any of the catalogue items with the same name. In that case, once there is more than one catalogue item here, more than one catalogue item may have variables that are listed in the order guide with the same name. If the user submits the usual form, the order guide form, and then goes to the second form, which is filling out the catalogue items, should the data be copied from the variables, the order guide variables, to the catalogue variables, or not? This is defined over the cascade variables.
If I check this, what happens is that I have “Hiring Manager” in the variables, and if I have the “Hiring Manager” variable in any of the catalogue items that are mentioned over here during the form submission, automatically the data will be copied to that particular variable. No need to write that field again and again. The variable set we requested is the best example. We can add that variable set over here, and we may have that variable set in all the other catalogue items. Also, usually we should open the catalogue item and fill out those fields for every catalogue item. But instead, as the order guide has the variables and we have filled them initially, we can utilise those values for all the catalogue items. So cascade variables are what they are. If we check it, it will be copied. If we are not checking it, then the data will not be copied. So that’s it. Regarding the catalogue items and the order guides in the next section, in the next lecture we are going to discuss workflow specific to the catalogue items.
4. Workflow – Specific to Catalog Items
In this session, we are going to discuss the workflows specific to the catalogue items. Let us go and create a workflow. We just need to type “workflow” in the left navigation pane. Once we click on it, it will open the window. So, as you can see, the workflow panel has come. I’m going to create a new workflow, whose name is “New Server Request.” This is for the catalogue item that we created earlier. Whenever we are writing any workflow specific to catalogue items, the table we need to select is always the requested item. So this is the table that should be selected when we want the workflow attached to any of the catalogue items. So that’s it. Now I’m going to submit here. What I can do are the two main activities: start and finish. As a result, these two activities will always be present in any workflow. I’m going to bring in an activity. This is only for testing purposes.
So I’m not going deep into the whole process. But let’s say I’m going to create a task. Assume we want the catalogue task, and this is the server creation. The task will then be completed sooner. We have seen that we can select different task types over here, like incident tasks or problem tasks. But as I have selected Catalog Task, this is greyed out, and it is only an underscore task. I can set the priority. I can set the fulfilment group. Let’s suppose I’m going to set the fulfilment group as the service desk and any one of the users from this team. Let’s select any other person or ITIL process again for server creation. This is what users see when they hover over the task. I can give you any instructions you want. I’m going to submit the request now. I can drag the branch, and what I can do is set values. So once the task is closed, I am going to close the requested item also. So the state is closed, and the set is finished. So that’s it. The workflow is ready for now, as this is a basic one and we have very few activities. Once we are done with the modifications, what we need to do is go to this and publish the workflow. Once it is published, we will not be able to make any modifications. If you want to make modifications, go to this workflow and click on Checkout again. And now we can make modifications to this workflow.
For now, let’s publish this and attach this workflow to the catalogue item. I’m going to open the catalogue item, the New Server catalogue item. Here we have this workflow. If in this workflow, I’m going to select the New Server Request workflow, and that’s it. I’m going to save the form. Let’s see if we can make this catalogue item request item. Now if we scroll down, we can see that a catalogue task is created automatically with the description that we have mentioned, and we can see the current workflow. Let us see that now. As you can see, this is the workflow context. Right now, it is waiting for the catalogue task to be completed. When we have created the workflow we have set, like when the catalogue task should be completed, we wait for its completion. So because of that, it is waiting for the catalogue task to be completed. Once it is completed automatically, the RATM state will be set to complete, and then the workflow will end. Let’s see that. If we come back to the workflow, if we open this catalogue task, we can see this waiting condition. So this is what I was talking about. Now let’s complete the task.
So this is the task, and I am going to set the state to closed complete. So you can see that the state is now set to “complete.” The RITM state is set to close complete.Even if we see the workflow over here, if we refresh this, you can see the path. So it has gone through this path. This is how the workflow will progress. The workflow will get attached, and then it will be floating if we come back to this, and if we see at the bottom that the task is closed, it is closed as complete. As can be seen here, So that’s it. This is how we create the catalogue items. We make the users submit that and we finally close the RATM based upon the workflow set. We create the work, we create the workflows inside those workflows, we create the approval records or we create the tasks, and we also create certain scripts so that our proper conditions will be executed. So that’s it. Regarding the catalogue items.
5. Knowledge Management
Hello, welcome back. In this session, we are going to discuss knowledge management in ServiceNow. Knowledge Management—I would say we can call it the library. We have KnowledgeArticles within ServiceNow that contain information about any of the issues or existing processes. These articles are written by us and saved in the knowledge base. Let’s start with the knowledge articles to see how they look. So if we type “knowledge” under the application menu “Knowledge,” we’ll be able to see certain modules. Let’s go ahead and click on the home page. This is the knowledge’s residence. Page. Let me minimise the navigator. As you can see, we have three different knowledge bases. There are two types of knowledge base articles. One is the knowledge base, and another is the knowledge categories. We have informational articles. These knowledge articles can be segregated based on categories. And again, these categories can come under different knowledge bases.
There is only one knowledge base for it, as you can see here. So all the articles related to it will fall under this particular knowledge base. And if generic knowledge is also a knowledge base, then with social QA you can create a knowledge base for your own business processes. If you want, you can create a knowledge base for HR, finance, or something like technical. When we enter the knowledge base, we will see various categories on the left. First of all, there are, I would say, six categories. Applications, devices, email, the operating system, and suppliers We may have subcategories under these, or we may not have any. At the center, we will be able to see the knowledge articles.
If I click on any of the Knowledge articles, Right now, under the Applications category, there are two knowledge articles. If I click on any of the articles, then that particular knowledge article will open up. This is the knowledge article. What is this Knowledge article about? It is all about managing settings, for example, 10 for Windows 8. So how can we manage the settings in Internet Explorer? This is something related to the information. Whatever information we want to save can be saved in knowledge articles, and users can access these knowledge articles. So that’s what it’s.Basically, as I said, it is just like a library. They can open the articles and get the information. Instead of asking someone, they can look through the knowledge articles and find the information they require. Let’s see how we can create knowledge articles. Before that. There are a few more things, which you can see over here. One is featured content, and then it is most useful and most viewed. Most viewed? This actually depends on the current instance, like how many people are viewing the most-viewed article that will be coming up.
The featured content can be controlled by us. There is a little list where we can add featured content; whatever articles we add will be coming up over here and on the knowledge base. If we want to make changes to any of the existing knowledge articles, we simply open the article and click the edit button at the top. Even we can read this article, and we can also comment on this article.If we scroll down, we can see this. We can also say whether it is helpful or not. So that’s the fundamental information about the Knowledge article. We have seen what the end users, or ITILs, say: “Let me again impersonate an ITIL and look into this particular knowledge.” Let me impersonate an end user. We’ll see how this guy looks in the knowledge articles. He will not be able to see the Knowledge application menu, but he can see the Knowledge homepage. If we click on this, the homepage will be opened. So this is again the same as the view of the administrator. There were a few buttons for admins, like importing articles, but as this guy is an end user, he won’t be able to create articles from here.
Let’s go ahead and look into the articles. Now that he can see all these articles, he can get information regarding them, and of course he can either comment, leave a comment, or even read this article. So everything is possible in this case. Even the end user—the person who doesn’t even have any role—can rate or comment on an article. But as you can see, he cannot edit an article. He will be able to create an incident, but he will not be able to edit an existing article. Now let’s impersonate the administrator and take a look at the administration part of Knowledge Articles. So as we saw a few minutes ago, there is an application called Knowledge that is solely for knowledge management. This section is entirely dedicated to articles, and if we hide it, we can see another section dedicated to US administration. By clicking on this link, we can create a new article in the articles section. If we click on it, you’ll see the page where we can create an article. This is the new record page for the Knowledge. We can create an orange article and utilise the base. We’ll talk about these very soon. We can set the validity based on information from, say, 1997 or something. If we are talking about Windows 97, it is of no use these days if there are any articles related to it.
As I said, we don’t require them right now. So, for any information, there may be an expiry date for that information. That is where we use the valid two. As a result, once this valid two is completed, this knowledge article will be retired. There are different states, or what I would call a “workflow,” for this knowledge article. What, for example, are the various states or stages of knowledge? According to the knowledge, it will first be in the draught state, and then it will be in the review state if there are any dissents. Then the people will review it, and once they approve it, it will move to the “Publish” state. So these are the states. As I said, there are two valid answers. When this particular knowledge expires, it will revert to its expired state. So these are the basic stages in any knowledge article. These are completely unique. If you want, we can create different states. However, there will be no requirement to create a new state for the time being. For this, we can actually use these out of the box states.Before creating the knowledge base, let’s see some existing knowledge articles. So these are the articles that are in the, I would say, “draft or review state,” as we can see the filter over the top.
Then there are the articles that have been published and are now being retired. It is not expired; it is a retired state. Okay, so these are the different states, and all these articles—whatever we click on—will actually be redirected to the knowledge base. Only knowledge articles are allowed. But there’s something else called the Submissions Table. If I click on all, we’ll see all the articles. Just look at the table’s name. It is knowledge. But if I click on “open submissions,” it will be the submissions table. KB Submissions table So before these articles, we can create a submission, and if it is okay, then we can move ahead with the knowledge article process. This is a very rarely used situation, but we can call it a sort of staging table. People can submit the knowledge articles and the knowledge submissions, and then, once it is okay, they will move the process to the knowledge articles. Now let’s get into the administration of knowledge articles. First, we have a knowledge base. In the knowledge base, we will be able to create a new knowledge base. By clicking on this new or existing knowledge base, we can look at the existing knowledge bases. We have seen these three bases over on the Knowledge homepage. It involves social QA and knowledge. Again, as I said, we can create a new knowledge base.
Let’s take a look at the knowledge base. For any of the knowledge bases, we have an important thing called an owner. So the owner is the person who will approve the knowledge articles. Whenever a knowledge article is created for this knowledge base, this is the person who will be approving the articles. Only if they approve will it go forward. That is defined in the published workflow, and the retirement workflow is also specified here. If we scroll down, we can see some extra articles and some extra related lists. One is knowledge, which is nothing but knowledge articles. All these 33 knowledge articles come under it, and we have categories. These are the categories we have seen on the homepage. Under these categories, we have the knowledge basis, or knowledge articles. If you want to create a category, you can either click on “New over here,” which will create a category under this knowledge base. Else, we can go ahead and go to the Knowledge category table, and then we can create the knowledge categories instead.
We can simply create the knowledge articles from here. Knowledge categories? Who can read these particular knowledge articles? This is nothing but user criteria. If we go into any of the user criteria, we can see the criteria. Like, if my company is Acme North America, only then can I see this knowledge base. If not, I won’t be able to see the knowledge base. This is similar to the user criteria we use in service catalogues to determine who can contribute, i.e. who can create articles in this knowledge base. Again, this is user criteria, and then we have featured content. Here is where we mentioned knowledge articles and keywords so that these particular knowledge articles will be shown in the featured content area. If we go to the home page, we will notice two featured contents; how did these two arrive here? It is from the place that we have seen. just now coming back to the user knowledge base Scroll down again. We receive questions about social giveaways, which are addressed in the knowledge articles. solet’s Have a look at these questions. Also, how do we raise these questions? If we return to the Knowledge Homepage, we can do so directly by clicking on this related link. So over here, if I minimise the navigator, I’m able to see a few links over the top. This is the post’s question. If I want to ask a question about any of the KB knowledge base topics, I can give it a title and a brief description. For this, I can also have a look at the knowledge base where I am going to create the question. So this is how we create the questions, as I discussed; let’s go ahead and look at the articles now. We are good with the knowledge base and the categories.
Let’s create an article and see how the workflow goes on.If we create an article, First of all, we need to select the knowledge base. Let me select it. And then there are the categories that are present in this knowledge base. Assume I am an android. In Android Mobile, we can say that rebooting is a problem. And now we can save the record, which means creating an article. Or, before submitting the article, we can search for duplicates. Once we click on it, what happens is basically I said it would search for the existing knowledge articles and that this form would not be altered. and a new tab. In a new tab, the search results will be displayed. As you can see, automatically, the search term has come over the top. You can see it over the top. Okay, now whatever knowledge articles are available with these particular words, they will pop up. in this particular content area. You can see I have mentioned Android, and it is highlighted. Android is highlighted. So. Android. Android. So whatever knowledge articles have these things, these words will be shown over these results. I can look over these articles if I want. And instead of creating if my issue or question is resolved, there is no need for me to create that specific article. If not, I can go ahead and create the article. So let’s create the article.
Now. We can see that the workflow is automatically set to draft. So, once I’m comfortable with this particular article, I can enter the text field where I can provide the knowledge article details, such as the rebooting issue in Android mobile. Assume you perform a hard reset. I can give steps 1, 2, and 3. Whatever it is, it is just a knowledge article. I’m providing specific information over here because I have the HTML tags. I can either keep them bold or change the font size. I can use whatever colours I want for the underscores. I can do anything with this. Now, once I’m good with this article, what I have to do is click on the “Publish” button. So that’s it. This knowledge item is in a review state. Whatever I had created was moved to the review state. So the one I’ve made is for the Android rebooting problem. So if we look over this particular layout, I have this workflow. This is the field that we were talking about, which actually shows the state. If I expand this, I can see that it is in the review state. Right now, this stage is complete. Right now, it is in the review stage. And next, it will be published. And next, it will be pending retirement. And finally, it will be retired. Let’s say I’m opening the article now because I clicked on “Publish” earlier. We have already discussed whether there will be approval for any of the articles.
This is the knowledge article. This is the knowledge base. The owner of this knowledge base will get approval if we scroll down. Yes, it has been this person who has received the approval. But why did he get the approval? If we hover over the icon, we can see that the owner is that person. Whenever we create an article, the knowledge-based owner will get the approval once he approves it automatically. As I am the administrator, I am going to approve this record. Let’s see what happens. Either I can approve or reject. If I approve it, we can see that the workflow state is published, so this is how we create the articles and manage the articles, but one question is, “How did the approval go for this particular person?” Like this knowledge base’s owner? Let’s go and look at the workflows. Now, if we type knowledge over here, we’ll see that there are many workflows. If you remember, this is the workflow that we have selected for the knowledge base. This is for publishing, and this is for retiring. Let’s have a quick look at the workflows. As you can see, once the request for the knowledge article is raised, it will go for approval, and when it is approved, it will set the workflow to publish. If it is not approved, it is setting the stage for the draft, and then it is going to end. So this is the basic process of knowledge publishing. And if you look at the retirement, there is a button called “retire” over the knowledge-based article. If we click on it, it will do certain scripting, and then it will go for approval again. Once approved, the state will be set to “retired,” or it will revert to its initial state. If it is rejected, then it will go back to the previous state. Previous state.
It would most probably be in a published state. So that’s it. This is the basic overflow of retirement. This is all about knowledge management in service. Now, consider knowledge articles. Again, it’s basically that they are like libraries. library of articles. We create articles in different categories and knowledge bases. These are utilised by all the people. Anyone can log into the system and look at the knowledge articles through the knowledge homepage. Only after a knowledge article has been approved will it be displayed on the knowledge homepage. If a knowledge article is under review, which means if it is not approved yet, we cannot see that knowledge article on the homepage once.If we feel that that particular knowledge article is obsolete, then we can retire it. Even the retirement process of a knowledge article goes through the same process. Once the retirement request is raised, the retirement, as you can see, is published it.And now I can click on “retired.” If I click on “Retired,” then that’s it; the retirement workflow will be triggered, and it will go for approval if it is retired. If it is approved, then the knowledge article goes to the “approved retired” state, as it will come back to the “published” state, so that’s related to the knowledge articles.
