Records in the Knowledge Article table represent FAQs, policies, user guides, and other reference information that is helpful in maintaining and improving the ITIL process. A knowledge article record has fields that are divided into tabs: Details, Progress, Source, Emails, and History. A small number of fields are stored in the common area, which is visible at the top of all of the other tabs.

Knowledge articles can be created by members of the admin, Admin Import, Base ServiceDesk, Business Admin, Knowledge Creator, ITIL Business Admin, Knowledge Manager, Marketing, and Project Manager groups.

Knowledge articles can be created by clicking New within the table view or by service desk personnel converting a resolved incident, service request, problem, or change request into an article.

If a user attempts to create a knowledge article with the same title as a previous knowledge article, the system will prevent the new article from being created until it has a unique title.

Knowledge topics are assigned to knowledge articles based on content. Users can subscribe to topics in order to get emails when new articles with those topics are created.

Knowledge Article Layout

This section details the key fields in a Knowledge Article.

Common Area

The common area of each Knowledge Article record shows the ID, which is unique within the Knowledge Article table and auto-assigned to each new record. In addition, the Status of the knowledge article is shown to provide information on the article's progress through the review and publishing stages. The default Status is Draft for new articles. Other Status options that can be used to track progress include Pending Document Manager, Pending Approval, Ready for Publication, Published, Retired, and Canceled.

The common area also contains an Assigned Team drop-down. The Assigned Team defaults to the Knowledge Management Team, but may be updated to hold another team. If an individual is responsible for the article, the name can be selected in the Assigned Person drop-down. The options for Assigned Person are filtered based on the selected Assigned Team.

The common area contains four buttons when the Status is Draft: Submit for Review, Submit for Approval, Clone Article for Revision, and Cancel this Document. Submit for Review changes the Status to Pending Document Manager and triggers an email to the Knowledge Management Team. Submit for Approval changes the Status to Pending Approval and triggers creation of approval records for each individual who has been selected as one of the Approvers on the Progress tab. Cancel this Document changes the Status to Canceled. Clone this Article for Revision opens a new knowledge article with some of the basic information mapped.

Details Tab

The Details tab of a knowledge article contains most of the basic information about the article. There are five main sections: Document Details, Document Files, Related Articles, Ratings, and Submitter Information.

Document Details

Knowledge Type is required and helps to categorize the article. Once a Knowledge Type is chosen, the Knowledge Subtypes will be filtered to the subtypes related to the Knowledge Type. Topic(s) should be selected based on the content of the article. If any users have subscribed to one of the topics chosen for this article, then they will receive an email when this article is published, notifying them that there is a new piece of information they might find interesting.
Priority and Rush can be used to indicate how quickly this article should be reviewed and published. The default of Rush is No.
Purpose and Description are used to explain the content of the article. HTML can be entered into the Description field by changing the radio button below it to HTML, or by clicking the Edit button.
Special Compliance Requirements is required, and one or more options can be selected. If any option besides None is chosen, Compliance Notes must be entered.
Document Access is required and used to identify who should be able to view this article. The options are Public, Partners, All Internal Users, Restricted to Specific Departments, and Restricted to Specific Users. If Restricted to Specific Departments is selected, a field appears allowing selection of one or more departments to which this article should be available. Similarly, if Restricted to Specific Users is selected, a field will be visible to allow lookup and selection of those users. Audience is an informational field, providing an overview of the types of people for which this article is intended.

Document Files

This section has information about the document itself. Source Files contains the original files used for the knowledge article. Published Format has several file types to represent the final, published version of the document. Once the article is published, the finalized document(s) can be added to the Published Files field. Both Source Files and Published Files accept document (Word, PDF, etc.) and image file types. If the file is stored at in internal URL, the URL can also be entered in the Internal File URL field.

Ratings

This section appears only once the status is set to Published or Retired. Users may rate articles by clicking on the "Rate this Article" button. Once an article has any ratings, they will appear in this section. The Overall Rating and Ratings Average fields show the average rating description and number for this article based on all ratings.

Submitter Information

This sections shows the Submitter's name and department. The submitter defaults to the person who created the knowledge article, but an admin or manager can edit the Submitter if the article was created on behalf of someone else.

Progress Tab

This tab holds approval information and notes on the knowledge article. Requires Approval is set to Yes if the article must be approved; if so, one or more Approver(s) can be selected. Once the article is submitted for approvals, an approval record for each approver will appear in the table of Approvals below. Any Approval Notes can be entered into the field manually. In addition, if any approvers write notes into an approval record, those notes are pushed to the Approval Notes here in the article.

Working Notes holds more general notes on the article's progress.

If there are milestones for the article, the Next Milestone Date can be stored. An article may also have a Final Due Date.

If revisions are needed and will be best handled with a service request, the button Raise a Service Request for Revision can be used. It opens a new service request record, mapping some of the information from the knowledge article. If this is done, any service requests created from the article will be shown in a table.

Services Tab

The Services tab contains a table of Associated Services. Services related to this article can be selected by clicking the lookup icon.

Source Tab

The Source field is used to specify where the knowledge article originated from, for instance from a change request, incident, problem, or service request. If there is a source record, the information is included below. When a knowledge article is created from within another record, such as an incident, the source incident details are automatically populated within the knowledge article.

History Tab

The History tab shows auto-generated dates: Date Created, Date Updated, Date Published, and Date Retired. It also keeps track of the user who created the record and the user who last updated the record. Below these fields, the History Events section contains a row for each time a change was made to the record, either by a user or a rule, and which fields were modified.

Knowledge Article Processing

This section describes how to create, review, and process Knowledge Articles.

Creating Articles

A knowledge article can be created by clicking New in the action bar of the main table view, or by clicking Create Knowledgebase Article within a Closed incident or service request, Completed change request, or Resolved problem. If created within an incident, service request, change request, or problem, the source record information is automatically populated into the knowledge article. In addition, some of the information from the source record is mapped into knowledge article fields, such as the article Title, Purpose, Attached Files, and Working Notes. Knowledge Articles start in a default Status of Draft.

For example, if Create Knowledge Article is clicked within a Closed incident, a new knowledge article record appears with the Title, Purpose, and Content fields prepopulated. These fields can be modified as needed. Additional required fields will also need values before saving the article.

Review and Approvals

Once an article has been created in a Status of Draft, it can be submitted for review by the Document Management Team by clicking Submit for Review. This changes the Status of the article to Pending Document Manager and sends an email to the Document Management Team. A document manager must then review the information, edit information if necessary, and either submit the article for approval or publish without approval. Alternatively, if the document manager determines that the Submitter must review the article or make additional changes, the manager can click Return to Submitter.

The field Requires Approval on the Progress tab indicates whether the article must be approved. The default value for this field is Yes, but can be set to No manually if approvals are not needed.

If approvals are not needed, the document manager will set Requires Approval to No and then can click Publish Without Approval. Clicking this button changes the Status of the article to Published.

If approvals are needed, the document manager will leave Requires Approval set to Yes on the Progress tab and select the users who need to approve from the Approver(s) lookup.

The approver(s) selected will appear in the Approver(s) field, and then the document manager will click Submit for Approval. This changes the Status to Pending Approval and generates an approval record for each of the approver(s) selected, then displayed in the Approvals table below.

For example, if Roxanne Marcin, Rick Peterson, and Ralph Knowles are listed as Approvers, they will each get an email asking them to review and approve the document. By default, any approver can approve at any time relative to other approvers. The approvers can click the hyperlink in the email to view the approval record, where additional details about the article can be accessed by clicking on the Knowledge Title.

Approvers can Approve, Require Changes for, or Permanently Reject the article. Any approval notes entered by approvers will appear in the Approval Notes field in the article. Once each approver has approved the article, the Status of the article is automatically changed to Ready for Publication. In addition, the Submitter and the Assigned Team receive an email alerting them that the article has been approved.

A knowledge manager may then click Publish, which changes the Status to Published. When an article is published and the Document Access is Public or All Internal Users, internal customers will be able to see the article. In addition, any users subscribed to one of the Topics for this article will receive an email about the new article.

Rejecting Articles

The reviewer may either approve or reject the article and provide Approval Notes. If the approval record is rejected, the reviewer must provide Approval Notes explaining why the document is rejected. A validation rule reminds the reviewer that they must provide rejection notes if a reviewer attempts to reject the approval without providing notes.

When any of the approvals are rejected, a rule in the Knowledge Article table detects this via a calculation on multiple linked records field that keeps track of the number of rejections. When this field is updated by rejections, the rule sets the Article's Status to Draft, emails the Submitter that the knowledge article requires an update, and sets a trigger field named Document Rejected, Requires Update in each of the linked approvals to Yes.

Setting the Document Rejected field to Yes in the approvals then triggers a rule that sets the Approval Status field in all of the linked approvals to Requires Reapproval, unless that Approval already has a value of Rejected.

Since any rejected Approvals set the Status of the document back to Draft, the process essentially starts over. The Submitter can review the comments made by the reviewers and see any red-lined documents that have been attached to the approval records. Then the Submitter edits the document and presses the Submit for Review button again to change the Status of the Document to Pending Review and notify the Document Manager. The Document Manager can then keep the same Reviewer(s) or change them and Submit for Approval again. If a document is rejected by an approver and then submitted for approval again (and the Status therefore changed from Pending Approval to Draft and back to Pending Approval), the status of all of the linked approvals is restored to Pending Approval, and all Reviewer(s) are notified by email.

Revising Knowledge Articles

If a document manager wants to create a revision for an existing knowledge article, there are two options: clone the article for the revision or create a service request for the revision.

To clone the article, click Clone Article for Revision. A new knowledge article record will appear with some information mapped from the source article, including Title, Assigned Team, Purpose, Content, Special Compliance Requirements, Compliance Notes, and Source Files. Additional information can be entered and pre-filled fields can be modified before saving the revision record. The default Status of the revision article is Draft.

To create a service request for a revision, navigate to the Revisions section on the Progress tab and click Raise a Service Request for Revision.

This will bring up a new service request record with Source Files is mapped into the service request's Attached Files. In addition, the Summary of the service request is set to "Revision of [knowledge article title]", the Business Service is set to Printing and Document Services, and the Service is set to Change to an existing knowledge article.

An Impact and Urgency must chosen prior to saving the new service request. In addition, an explanation of the revision should be added to the Description field. More information about the knowledge article being revised is visible on the Related Records tab. The source knowledge article is populated automatically.

In the knowledge article, the service request for revision is automatically appended to a table of Service Requests on the Progress tab.

Retiring Knowledge Articles

After an article is Published, if it is no longer needed, it can be retired by a document manager using the Mark Retired button. Clicking this button changes the Status of the article to Retired.

Knowledge Subscriptions

Users can receive notifications about Knowledge Articles of interest by subscribing to topics.

Subscribing to Knowledge Topics

Each knowledge article can be associated with one or more topics such as Security, HR, or Confluence. Categorizing articles makes it easier to search for knowledge articles about specific topics. When users subscribe to a topic, such as Confluence, they receive an email when an article about Confluence is published.

Users can subscribe to topics by clicking on My Profile in the end user interface. At the bottom of the first tab, a drop-down of topics is visible. All topics are listed in the dropdown, minus any the user is already subscribed to. To subscribe, the user selects the topic and clicks Subscribe to Topic.

When the screen refreshes it shows the topic listed as one of the user's topics. In addition, a pop-up confirms that their subscription was successful.

Rating Knowledge Articles

Any user who reads a knowledge article can give it a rating by clicking Rate this Article. A new record will appear where the rating information can be entered.

Automation

When a knowledge article is created, the following actions run:

If the Status is Pending Document Manager, an email is sent to the Knowledge Management Team to let them know that the document is ready for their review.
If the article orginated from a service request, incident, problem, or change request, the source record is updated to link to the new article.

When a knowledge article is edited, the following actions run:

If a user saves the article when the Status is Pending Approval and Requires Approval is set to Yes, but no Approvers have been selected, a validation prevents saving the article.
If a user changes the Status to Published or Ready for Publication and and there are still approvals that have not been completed, a validation will warn the user that the approval process is not complete.
If the Status changed from Pending Approval back to Draft, an email is sent to the Submitter to let them know that the document requires updates.
If the Status changed to Published, an email is sent to the Submitter.
If the Status changed to Pending Document Manager, an email is sent to the Knowledge Management Team to let them know the article is ready to be reviewed.
If the Status changed to Ready for Publication, an email is sent to the Submitter.
If the Status changes from Draft or Pending Document Manager to Pending Approval and there are approvals pending, all linked approvals are set to Pending Approval.
If the Status changes to Published and there are Topics selected, an email is sent to all of the subscribers to each of the topics.
If the Approver(s) are updated, each approver's profile record is flagged in order to trigger creation of approval records.
When all approvals are completed for the article, the Status is set to Ready for Publication and emails are sent to the Submitter and the Assigned Team.

Workflow

The following diagram represents the different knowledge article states and the allowed transitions between the states.

Reports

Knowledge Article reports are listed below.

Evaluating Knowledge Article Usage

Information about how many users have viewed a knowledge article in a certain time can be captured. Several reports have been created to summarize this information. For example, one chart in the Activity Log table shows the number of file views per knowledge article each month.

Additional details on who viewed the file and when are part of this report as well.

In addition to looking at file views, record views can also be included in reports. This information can be used to assess what types of knowledge are most useful or have been relevant over the past month.

Evaluating Knowledge Article Need

Reports in other tables can also provide information relevant to knowledge. For instance, this report of Closure Categories for incidents gives information on what types of incidents are occurring most frequently and what kinds of improvements can be made. Again, more details about the data used to generate this report are readily available in the HTML portion.

Checking for Similar Knowledge Articles

To help identify redundant information, as well as to provide information about what types of knowledge are being published, there is a report called All Active Knowledge Articles, grouped by Knowledge Subtype. The more detailed list of articles published within the same Knowledge Subtype can be used to easily determine which articles may be able to be combined.

Page tree

Knowledge Articles