When creating, editing, or viewing knowledge articles in ServiceNow, you will encounter multiple templates. These templates share many of the same fields, like "Short description", which serves as a title for your article. Each template also has unique fields that exist only on that template.

Shared fields

Jump to: Unique fields

"Template" field (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, 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" field

• Draft - You are still working on it. The content is unpublished and available for editing. It can be accessed by the original author by going to lists and then Knowledge > Your unpublished 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 by going to lists and then Knowledge > Your unpublished 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" field

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" field

• 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.
• Always go to the deepest level of categorization. As an example, consider that you are creating an article about troubleshooting in Microsoft Teams. A categorization exists that is Business and Productivity Applications//Microsoft Teams//Troubleshooting. You would not pick Microsoft Teams as the category. Go a level deeper and choose Troubleshooting as the category. Also, you would never pick Microsoft Teams as a category for any article. If options exist below that level, always use one of those. If one doesn't exist that makes sense, ask one of your knowledge base administrators to create one. In the meantime, either leave the category empty or pick something at the deepest level.
• 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" field

• Knowledge articles have a designated "Valid to" date. By default, this date is 1/1/2100, but it can be manually changed to be sooner or later once the article is published.
• On the first day of each month, the application sends an email notification to a list of authorized recipients to remind them about articles that are about to expire in the next month. The recipient can then extend the Valid to date to continue using the article.
• Articles do not appear in search results after the "Valid to" date or if the "Valid to" date is blank.

"Short description" field (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.

"Meta" field

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 describe 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. 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: "how to steps directions instructions mobile phone smartphone cell Samsung Galaxy Google Pixel 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.

Unique fields

For details about each template's unique fields, click the link below for the desired template.

• FAQ
• How to
• Incident article
• What is