Knowledge base templates in ServiceNow


Explanation

Template (required)

Template types

Not all templates may be available in all knowledge bases.

  • How to - How-to articles
  • What is - Overview of, Information about, or Definition of
  • Incident article - Audience is experiencing a problem or an error message
  • FAQ - Frequently asked questions
Troubleshooting guides

If you need to create a troubleshooting guide, try to use the "Incident article" template and frame the article in the customer's context. You can put keywords like "troubleshoot" and "guide" for those individual who may search for a troubleshooting guide.

EXAMPLE: If you're thinking of creating a "How to" article with a short description like "How to: Troubleshoot problems accessing websites on your Android phone", instead use the "Incident article" template and title your article something like "Problems accessing websites on your Android phone".

If you need to create a specific troubleshooting guide and you're concerned that your audience may not find it within an "Incident article" framed in the customer's context, you may create the guide separately using the "How to" template. However, this is an exception and shouldn't happen often. If you do this, you must still create an "Incident article" in the customer's context and link to your guide from within that "Incident article".

Workflow

  • Draft - You are still working on it. The content is unpublished and available for editing. It can be accessed by the original author in Self Service > My Knowledge Articles. Updates can be saved while keeping the article in "Draft" state.
  • Review - The draft version of the article is sent to reviewers to approve or reject. After choosing "Publish" on an article, the article will be placed in "Review" if it is submitted to a knowledge base that requires approval before publishing new articles. An article may also be placed in "Review" if it is published, then edited, and lives in a knowledge base that requires approval before publishing updates to existing articles. Articles in the "Review" state can be accessed and edited by the original author in Self Service > My Knowledge Articles. Approvals are completed by knowledge base managers.
  • Scheduled for publish - The draft version of a knowledge article is scheduled for publishing on a future date. The knowledge article is published on the scheduled publish date depending on the following workflow settings of its knowledge base:
    • If the knowledge base workflow is set to "Knowledge - Instant Publish", the knowledge article is automatically published on the scheduled publish date. The "Workflow" field on the knowledge form of the article is updated to "Scheduled for publish".
    • If the knowledge base workflow is set to "Knowledge - Approval Publish", the knowledge article is published on approval completion. The "Workflow" field on the knowledge form of the article is updated to "Review". The approval completion affects the scheduled publishing as follows:
      • If the approvals are completed before the scheduled publish date, the "Workflow" field on the knowledge form of the article is updated to "Scheduled for publish" and the article is published on the scheduled publish date.
      • If the approvals are completed after the scheduled publish date, the article is published immediately on the approval completion.
  • Published - The article is approved to be viewed by the intended audience. It is visible to all users with read access, and it will appear in knowledge searches and global searches. When the state of an article changes to "Published", the state of any previous published versions of that article changes to "Outdated".
  • Pending retirement - After choosing "Retire" on an article, the article will be placed in "Pending retirement" if it resides in a knowledge base that requires approval before retiring articles. Approvals are completed by knowledge base managers.
  • Retired - There is no anticipation of using the article again. An article in "Retired" state is visible only to the owner and manager(s) of the knowledge base where the article resides. It will not appear in knowledge searches or global searches. To reuse a retired article, create a new article with the same content, which is published once approved. If for whatever reason it's not desirable to create a new article, a retired article can be returned to "Draft" state to return to the workflow if it becomes relevant again or is retired by mistake.
  • Outdated - A more recent version of the article has been published.

Can read

This field allows you to specify user criteria for a knowledge article to control which users are granted read access to the article. In other words, this field allows you to set different permissions for viewing one particular article than the permissions that apply to the entire knowledge base.

Category

  • Attempt to find the best category to match the article on which you are working.
  • Categories make it easy for your audience to find the article by browsing instead of searching.
  • Choose the category that is the most likely one your audience would use when browsing by category.
  • When picking a category, think, "Would a customer browse for this article by choosing this category?" For example, if we are creating content on how to do something in Outlook 365 on Windows 11, someone might browse via an Outlook for Windows category, and someone might browse via a TechMail category, but it is not likely that someone would browse under Windows 11.

Valid to

  • Knowledge articles have a designated "Valid to" date. By default, this date is one year from the date of creation, but it can be manually changed to be sooner or later once the article is published.
  • Every time an article is edited, the "Valid to" date will automatically update to one year from the date of the edit. As long as you are regularly updating articles, you will not generally need to worry about the "Valid to" date.
  • When an article passes its "Valid to" date while published, the knowledge article's owner will receive a notification that the article needs to be reviewed and the "Valid to" date reset. If no knowledge article owner is indicated on the article, the knowledge base manager(s) will receive a notification.
  • Articles past their "Valid to" date will still be visible to end users as long as they remain in the "Published" state.

Short description (required)

  • Use sentence case.
  • Start with "How to:" for instructional articles.
  • Start with "Error:" for articles with an exact error message. Put the error message inside quotation marks.
  • For articles about a problem when there is no exact error message, state the problem
  • Start with "Overview of" for articles that are an overview of a particular service or software.
  • Start with "Definition of" for articles that are primarily a definition of a term.
  • Start with "How to: Get assistance with" for articles about how to get help with a particular service or software package.
  • Start with "Information about" when it makes sense and when "Overview of" and "Definition of" are not appropriate.

Introduction ["How to" and "What is" articles only]

Use this field to optionally provide introductory text to the "Instructions" or "Explanation" fields.

Instructions ["How to" articles only]

  • This is where the bulk of the info for your article will be located.
  • Create an outcome section to provide a conclusion to the action. Click Insert, then click Horizontal line on the toolbar followed by the word "OUTCOME" in all upper-case letters on its own line; place the outcome details below it. Write the outcome in present tense whenever possible.
  • If you are only uploading the instructions in an attachment like a PDF or a Word document, type "Please see the attached file(s)." Then, check the "Display attachments" checkbox.

Explanation ["What is" articles only]

  • This is where the bulk of the info for your article will be located.
  • If you are only uploading the instructions in an attachment like a PDF or a Word document, type "Please see the attached file(s)." Then, check the "Display attachments" checkbox.

Symptoms ["Incident articles" only]

  • When using the "Incident article" template, the "Short description" field normally contains a statement of the problem. The "Symptoms" field can be used to provide more details on the problem or to state the problem in a different way, if needed. It is not required to have content in the "Symptoms" field, and you should not use it unless it adds value to your article.
  • Provide screenshots, when possible.
  • For errors, even if there is a screenshot, type out the exact, entire error message as it appears in the audience's context. This makes the text searchable. If appropriate, include text before or after the error to set up the context of under what circumstances the error occurs.
  • If there is more than one potential error message, you can document them in two different KB articles; or you can put section headers above each bit of error text to delineate "ErrorĀ 1" and "ErrorĀ 2", for instance.
  • Style guidelines for errors are included in Formatting and style guide for knowledge base articles.
  • Replace variables in error messages with generic text, and italicize any variables.

Cause ["Incident articles" only]

  • The reason that the error or problem occurred
  • For the "Incident article" template, always specify a cause. If the cause is unknown, type "Unknown".

Resolution ["Incident articles" only]

  • Use this field to provide the solution for the problem or error. Always specify something. If there is no solution at the time you create your draft, then type, "There is no known resolution at this time."
  • Provide details of how to resolve the error or problem, with step by step directions, bullet lists, screenshots, or whatever might be necessary.
  • Create an outcome section to provide a conclusion to the action. Click Insert, then click Horizontal line on the toolbar followed by the word "OUTCOME" in all upper-case letters on its own line; place the outcome details below it. Write the outcome in present tense whenever possible.

Workaround ["Incident articles" only]

  • When the problem or error has no known resolution, there may be a workaround. Include that info in this field.
  • An example of a workaround might be using Safari to access a website instead of Chrome.

Question ["FAQ" articles only]

For "FAQ" articles, the content for the question.

Answer ["FAQ" articles only]

For "FAQ" articles, the content for the answer.

Meta (required)

NOTE: The "Meta" field is only visible to those with access to contribute to the knowledge base. The audience cannot see this field or its contents.

  • Place keywords in the "Meta" field. Keywords are important to the findability of your article. The best content in the world isn't useful if the audience can't find it.
  • The "Meta" field should include words that might help your audience find the article, especially words not found elsewhere in the article. If the article is being created from the result of a customer interaction, please use words that the customer used to desribe the problem or the request. Customer context is key to findability!
  • Keywords may be words already found in the "Short description" or in other fields in the article. You may choose to do this because the "Meta" field is weighted more heavily than other fields when computing the search relevance. Make sure that your keywords include the most important words for what the article is regarding. For instance, if your article is about setting up TechMail on Android, you would always make sure words are included like the following: "cell mobile phone smartphone Android configure setup set up add account email mail TechMail TTU ttu.edu Texas Tech University Microsoft365 Microsoft Office 365 Office365 O365 M365".
  • Try to think of what someone might search for if they were looking for the content you're seeking to create. Put yourself in their place.
  • Think of synonyms for words that you've used. You might search for "privileges" while someone else might think of "permission" or "rights". Try to include all such words. You might choose to search for "website" while someone else would type "web page". Use as many different types of words like this as possible when populating the "Meta" field.
  • Group words in "Meta" that would normally go together (for instance, Adobe Creative Cloud). This is because when people enter these terms into the search field, the search algorithm will first look for them in the order they were typed. If you have them separated instead of together, your article will rank lower in the search results that appear.

Knowledge blocks

  • To insert a knowledge block, place your cursor in the location in the field where you wish to insert it. Click the Add Blocks button. Find the knowledge block that you want to use and click Insert. (You may also view what the knowledge block contains by clicking the View button.)
  • Familiarize yourself with the knowledge blocks available so that you do not re-create content already available as a block.