Introduction

This document provides a clear and detailed guide for maintaining the Office of Information Technology (OIT) Public Knowledge Base (KB). In this knowledge base, “public” means unauthenticated users and all Unity accounts can access content. The majority of content, however, is available for unauthenticated users. The primary objective is to institute standardized practices and processes to streamline knowledge management within OIT. User self-service will improve, thus leading to fewer Help Desk requests when we ensure that all OIT Public Knowledge Base articles are relevant, accurate and accessible.

When To Use This Guide

This document is a resource for all OIT knowledge contributors to use as a reference when creating and editing Knowledge Base Articles (KBAs) in the OIT Public Knowledge Base.

Help With These Guidelines

If you have questions or need assistance with knowledge management, contact the NC State Help Desk via the NC State IT Service Portal or call 919.515.HELP (4357).

Training

In order to contribute to knowledge, you must complete the required training. Completion is necessary to gain access to the knowledge base. If you need additional guidance on the ServiceNow platform, visit learning.servicenow.com and click Start Learning. Once you have created a Now Learning account, you will be able to browse the available training courses. Please note that ServiceNow regularly retires and updates their courses.

Workflow

All OIT knowledge management processes adhere to the Knowledge-Centered Success (KCS) demand-driven model of Capture, Reuse and Improve. Simply put, when an issue or demand arises, it is “captured,” or documented, by the Knowledge Worker. The Knowledge Worker then searches the KB to see if there is an already existing Knowledge Base Article (KBA) that provides a resolution to the issue. If there is, the Knowledge Worker scans the article for accuracy and if it is indeed up-to-date and accurate, the KBA is used to solve the issue. If, however, the KBA found is not up-to-date or accurate, the Knowledge Worker must submit a knowledge feedback task containing meaningful information so the original author can revise it. If the Knowledge Worker has the appropriate access and expertise, they can and should revise the article themself. The updated KBA can then be used to solve the issue. When the Knowledge Worker initially searches the KB, if no relevant KBA’s exist, it is their responsibility to create the new KBA. 

Searching is a crucial step in this workflow and must not be overlooked. Searching early and often helps avoid redundancy and keeps the KB uncluttered.

When Do I Create a New Knowledge Base Article?

It is important to know when it is appropriate to create a new KBA. OIT has adopted a demand-driven approach to Knowledge Management. This means that a new KBA is created only when a) there is a “demand” and b) there is no existing KBA that addresses this demand. We are not imagining, anticipating or fabricating issues that have not yet happened. While we may want to be proactive, we should resist the temptation to predict the future. So, what is a “demand”? A demand can be a formal interaction through a ticket in the portal. It can also be an informal question or a discussion between colleagues. 

Article Lifecycle

All KBA’s go through a process of Draft, Publish and Expiration. The stages are referred to as Workflow States. The current Workflow State is displayed in the upper right corner of the edit screen.

• Draft: Draft is the first stage in which the article is created. In this stage, the Knowledge Worker first searches the KB for duplicate articles. If no such articles exist then the Knowledge Worker creates the article, enriched with detailed information while adhering to the provided style guide and accessibility requirements. The author should also ensure any links are valid prior to proceeding to publication.
• Publish: The next stage is to Publish the article. Publishing the article makes it visible to end users in the KB.
• Maintenance: After publishing, a KBA is considered to be in the Maintenance phase where we, as Knowledge Workers, maintain the accuracy of the article. This can also be considered a “review” phase. Any time a Knowledge Worker comes across an article in their work they are technically “reviewing” that article as every use is a review. Knowledge Management is a collaborative effort. Just because an article may have been authored originally by someone else, if you happen upon the article and discover corrections that need to be made, it is your responsibility to make those corrections in the moment. If you are unable to do so, please submit a knowledge feedback task and follow up with the author and/or the Subject Matter Expert (SME) to ensure the article is updated. Visit go.ncsu.edu/KBAfeedback for more information on submitting knowledge feedback tasks. After a published article is edited, the versioning information automatically updates in the ServiceNow platform.
• Expiration: The final stage is article Expiration. An article will automatically expire when it reaches its Valid To date. The original author will be notified in advance which gives them time to review. If the KBA is still necessary and accurate then the article can be updated with a new Valid To date. If the article needs to be updated, the original author must do so then publish with a new Valid To date. If the article is obsolete and no longer needed then the article may be submitted for Retirement.

Article Requirements

When creating a new KBA or editing an existing KBA, there are several fields that need to be completed. 

• Knowledge base*: Click inside the field and select Public Knowledge as the Knowledge Base. 
• Category*: There are two methods for choosing a category. The first is to click the magnifying glass and select the category that best suits your article. The second method is to type an asterisk followed by a keyword directly in the category field (ex. *password or *education). If you cannot find an appropriate category, choose the next closest category available and then submit a Help Desk incident requesting that a new category be created. Include the KBA number and the proposed new category in your incident request. 
• Scheduled publish date: This is where you can indicate if you would like the KBA to be published and available at a future date.
• Valid to*: By this date, the article must be reviewed or it will expire and no longer be accessible to the end user. Select a date no more than one year in the future from date of publication.
• Short Description*: This will be the title of the article. Select a title that uses language your intended audience would use to search for related information.
• Article body*: This is where you put the article content. The structure will vary depending upon the type of KBA you are creating/editing and whether or not you are using a pre-existing template. 
• Meta: This is where you can enter search terms or words and phrases separated by commas to help the relevant KBA appear when those terms are searched in the Knowledge Base. If all the important keywords and phrases are included in the article title, body or any other field, you don't need to use the Meta field. The Meta field can be useful for common misspellings, colloquialisms, acronyms and technical jargon.
• Can Read*: This is a field that controls the visibility of an article. If you want your KBA to only be accessible to users with a Unity account, for example, you can specify “campus - authenticated” as the user criteria in this field. Please note that the OIT Public Knowledge Base is intended to provide information to as wide an audience as possible. If you need to limit access, consider placing your article in a more restricted knowledge base. For more information on user criteria, click the “Can Read” hyperlink in ServiceNow or visit Knowledge Article Permissions.

*indicates a required field.

Roles

The extent to which you are able to use the Knowledge Base depends on your permissions. The different roles for the OIT Public Knowledge Base are: 

• Knowledge Base Owner/Manager: Users with this role can manage KB settings, permissions and categories; create, modify and publish articles; retire articles; view all articles.
• Knowledge Base Contributors: Users with this role can create, modify and publish articles; submit articles for retirement; view all articles.

Templates

Some Knowledge Workers prefer to use a template when drafting a new KBA. To learn more about KBA templates, visit go.ncsu.edu/ServiceNowFormTemplates.

Categories

All articles are assigned to a category or subcategory. These categories and subcategories provide structure and organization to our knowledge base. You can see the category structure by clicking the magnifying glass in the Category field when creating or editing an article. If you have suggestions for updating the existing categories or subcategories, please reach out to your manager, unit liaison, or submit a ticket to the NC State Help Desk.

Before You Publish

Included below is a non-exhaustive list of items you should check prior to publishing an article.

• Ensure the article is unique. If the article is creating redundancy, there is no need to proceed further. Do not publish this article.
• To reduce complexity and improve readability, consider leveraging multimedia, limiting the use of technical jargon, and linking external resources or training for reference. You can also ask a peer or SME to review the article for accuracy.
• Ensure the article has an appropriate title and that all required fields are filled out.
• Check that all links resolve correctly.
• Make sure the article meets both Style and Accessibility guidelines.

Style

Please refer to and follow guidelines indicated in the official OIT Style Guide. 

Accessibility

Use the list below to check your KBAs for accessibility. Visit go.ncsu.edu/KBAaccessibility for more information.

• Structure: Use the built-in style tools to select headings and organize structure. Use only one Heading 1 per article and do not skip heading levels.
• Lists: Use the built-in bullet and number list tools. Unordered lists should use bullets and ordered lists should use numbers.
• Links: Use the Link tool to create meaningful text descriptions that make sense out of context. Phrases such as "click here," "more," and "click for details," are ambiguous when read out of context.
• Alternative text: All pictures, charts and graphs must have alternative text that describes both the content and function of the image.
• Tables: Use the built-in table tool for data and not for layout purposes. Indicate a heading row or column in the corresponding properties menu. Avoid merging and splitting cells. Add a brief explanation above the table, if needed.
• Color: Do not use color as the only means of conveying information, indicating an action, or distinguishing a visual element. Make sure you have sufficient contrast between background and foreground elements. Consult the WebAIM Contrast Checker.
• Multimedia: Include videos that are both visually and aurally descriptive, which means having accurate captioning and narrating what is only visually represented in the video if it is providing information. Automatically generated captions must be edited for accuracy.