NetResults Tracker Help
The Knowledge Base Template

Overview

The Knowledge Base template supports a process to compose, review and publish Knowledge Base articles that are searchable by end users. Typical of this process is the immediate posting of articles so end users can access the most up to date information. This model assumes the following organizations are involved in the process:

Support
Responsible for composing, publishing, and maintaining the Knowledge Base articles

Development
Responsible for reviewing the articles for technical accuracy

Publications
Responsible for reviewing articles for consistency with other documentation


Projects

A default project called "Knowledge Base" is available in this template and is visible to all user groups. This project can be customized and additional projects can be added via the Projects section.


Forms

A default form called "Article" is available in this template, is associated with the "Knowledge Base" Project and is visible to all user groups. This form can be customized and additional forms can be added via the Forms section.


Fields

The Article form contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values via the Fields section. Field names with an asterisk are required by the system and cannot be removed from any form(s).
Article ID* Numeric record identifier. Assigned at the time the article is created.
Title A one line text summary of the article. Set at the time the article is created.
Article Type Classifies the article. Possible values are: Defect, Hot Fix, Tech Note, and Unknown. Set at the time the article is created.
Last Updated Date* The date and time the article was last modified. Set automatically as the article is processed through the workflow.
Product* Identifies the product for which the article has been composed. Set at the time the article is created.
Version Identifies the version of the product to which the article pertains. Set at the time the article is created.
Oldest Version Identifies the oldest article in a range of versions to which the article is applicable. Values displayed in this field depend on the value selected in the Version field. Set at the time the article is created.
Newest Version Identifies the newest article in a range of versions to which the article is applicable. Values displayed in this field depend on the value selected in the Version field. Set at the time the article is created.
Severity Indicates the level of severity of the article's subject. Set at the time the article is created.
Description Full details of the article. Ideally describes the nature of an issue or a procedure and how to resolve it or perform a set of steps. Set at the time the article is created.
Workaround Describes how to work around the problem described in the article. Set at the time the article is created.
Status* Current state of the article. Changes as the article is processed through the workflow.
Assigned To* User the article is currently assigned to for processing. Set either manually or automatically during processing of the workflow.
Author* Name of the user that composed the article. Initially set to the name of the current user logged in. Set at the time the article is created.
First Draft Date The date the article was created. Automatically initialized, and set at the time the article is created.
Dev Comments Describes the comments made by the Developer reviewing the article. Set after review by a member of the Developers group.
Pubs Comments Describes the comments made by the Publications user reviewing the article. Set after review by a member of the Publications group.
Support Notes Describes the response from the Author (usually a member of the Support group) about the comments resulting from the reviews made by the Development and Publications groups. Set after review by the Author.
Publication Date The date the article was published. Automatically initialized, and set at the time the article is published as part of the workflow.
Archive Date Date when the article was removed from the Knowledge Base. Set by Support when the article has become obsolete or was replaced by a newer article. Automatically initialized to the current date/time.
Deleted* Denotes whether the article has been deleted.

Dependent Pulldowns

The pulldown fields Oldest Version and Newest Version are dependent on the pulldown field called Version to create a range that describes which versions are affected by the content of an article.

The Version field has the option menu values:

Unknown
Version 1
Version 2
Multiple Versions

Oldest Version has the option menu values:

Unknown
1.0.0
1.0.1
1.5.0
2.0.0
2.0.1
2.0.2

Newest Version has the option menu values:

Unknown
1.0.0
1.0.1
1.5.0
2.0.0
2.0.1
2.0.2
Latest Release

The examples below illustrate the dependencies between Version and the Oldest Version and Newest Version:

Article content applies to Versions 1.x only
Version field set to "Version 1". Selecting this value for the Version field will result in the Oldest Version and Newest Version fields only displaying those option menu values that start with "1".
Oldest Version set to "1.0.0"
Newest Version set to "1.5.0"

Article content applies to Versions 1.5.0 through latest version
Version field set to "Multiple Versions". Selecting this value for the Version field will result in the Oldest and Newest Version fields displaying all possible values.
Oldest Version set to "1.5.0"
Newest Version set to "Latest Release"

Details on setting up dependencies between pulldown fields can be found in the Customizing Pulldown Dependencies section of the Admin Guide.


Workflows

It is assumed that articles will be processed and moved through the workflow process by using the Task operation. A default workflow called "KB Article Process" is available in this template and is associated with the "Article" Form and is in use in the "Knowledge Base" Project. You can customize the KB Article Process workflow or add additional workflows via the Workflows section.

  1. State 1 - Pending Dev Review
    When an article is created, it is set to the state Pending Dev Review, and assigned to the Development Manager (dev_mgr). It is assumed that the Development Manager is responsible for assigning the article to a Developer (a member of the "Developers" user group) to review and comment on the article's technical accuracy. The Development Manager uses the transition called Assign to Developer For Review, which sets the article's state to In Dev Review and prompts the Development Manager to select a user from the list of members of the Developers user group.

    This is implemented by:

    Workflow Properties

    • Defining Pending Dev Review as the Default Add State when an article is added
    • Assigning the dev_mgr user as the manager for the Pending Dev Review state

    Transitions

    • Defining a transition to move an article to the In Dev Review state where the assignee is the Developer selected by dev_mgr during the Task operation

  2. State 2 - In Dev Review
    The Developer (dev_one) reviews the article for technical accuracy, then decides whether to approve or reject the article by choosing the corresponding transition. To approve the article, dev_one selects the transition Approve Article and provides any desired comments in the Dev Comments field. This results in the article being placed in the Pending Pubs Review state and is assigned to the Publications Manager. To reject the article, dev_one selects the transition Reject Article and must provide comments to describe why the article was rejected in the Dev Comments field. This results in the article being placed in the Rejected By Dev state and assigned to the Author (Reporter).

    This is implemented by:

    Workflow Properties

    • Selecting Pubs Manager as the state manager for the Pending Pubs Review state

    Transitions

    • Defining a transition to move an article to the Pending Pubs review state with the assignee set to be the state manager
    • Defining a transition to move an article to the Rejected By Dev state with the <Reporter> set as the new assignee

    Task Fields

    • Configuring Dev Comments (optional) to be presented during the task operation for the transition to the Pending Pubs Review state
    • Configuring Dev Comments (required) to be presented during the task operation for the transition to the Rejected By Dev state

  3. State 3 - Pending Pubs Review
    The Publications Manager (pubs_mgr) is responsible for assigning the article to a Publications Reviewer (a member of the Publications user group) to review and comment on the article so that it is consistent with all other documentation. The Publications Manager uses the transition called Assign to Pubs Reviewer, which sets the article's state to In Pubs Review and prompts the Publications Manager to select a user from the list of members of the Publications user group.

    This is implemented by:

    Transitions

    • Defining a transition to move an article to the In Pubs Review state where the assignee is the Publications Reviewer selected by pubs_mgr during the task operation

  4. State 4 - In Pubs Review
    The Publications Reviewer (pubs_one) reviews the article for its consistency with respect to other documentation, then decides whether to approve or reject the article by choosing the corresponding transition. To approve the article, pubs_one selects the transition Approve Article and provides any desired comments in the Pubs Comments field. This results in the article being placed in the In Final Author Review state and is assigned to the Author (Reporter). To reject the article, pubs_one selects the transition Reject Article and must provide comments to describe why the article was rejected in the Pubs Comments field. This results in the article being placed in the Rejected By Pubs state and assigned to the Author (Reporter).

    This is implemented by:

    Transitions

    • Defining a transition to move an article to the In Final Author Review state with the assignee set to be the <Reporter>
    • Defining a transition to move an article to the Rejected By Pubs state with the <Reporter> set as the new assignee

    Task Fields

    • Configuring Pubs Comments (optional) to be presented during the task operation for the transition to the In Final Author Review state
    • Configuring Pubs Comments (required) to be presented during the task operation for the transition to the Rejected By Pubs state

  5. State 5 - In Final Author Review
    The Author (Reporter) reviews the article one last time before publishing it to the Knowledge Base. To do this, the Author selects the transition Publish to Knowledge Base and enters any desired information into the Support Comments field. The Publication Date is automatically initialized with the date and time. This will place the article in the Published in KB state and assign it to TBD.

    This is implemented by:

    Transitions

    • Defining a transition to move an article to the Published in KB state where the assignee is TBD ("no one" since it is now published)

    Task Fields

    • Configuring Support Comments (optional) and Publications Date (read only and initialized) to be presented during the Task operation for the transition to the Published in KB state.

  6. State 6 - Published in KB
    Articles in this state are searchable via the Knowledge Base Search Page and are assigned to TBD. An article may become obsolete and thus will need to be updated or removed from the Knowledge Base by the Support Engineer (sup_one). To update an article, Support can use the transition Update Active (in KB) Article. This transition allows sup_one the option to update any of the following fields: Title, Article Type, Product, Version, Oldest Version, Newest Version, Severity, Description, and Workaround. sup_one is then required to enter a history comment. After making any changes, the article will remain in the Published in KB state, assigned to TBD. To remove an article from being searchable in the Knowledge Base, sup_one can select the transition Archive (Remove From Knowledge Base) and must enter a history comment. This transition will place the article in the Archived (obsolete) state, assigned to TBD. The Archive Date will be automatically initialized with the date and time.

    This is implemented by:

    Transitions

    • Defining a transition to update fields in the article with New State set to the same state (Published in KB) and New Assignee set to <Same Assignee> with history comment set to be required
    • Defining a transition to move the article to the Archived (obsolete) state and assigned to TBD ("no one" since the article is obsolete) with history comment set to be required

    Task Fields

    • Configuring all of the following fields to be optional fields presented during the task operation for the transition to update the article: Title, Article Type, Product, Version, Oldest Version, Newest Version, Severity, Description, and Workaround
    • Configuring Archive Date (read only and initialized) as a field to be presented during the task operation for the transition to the Archived (obsolete) state

  7. State 10 - Archived (obsolete)
    This state indicates that the article contains obsolete information and is no longer searchable in the Knowledge Base

  8. State 20 - Rejected By Dev
    Articles in this state were rejected during the review made by a Developer. sup_one must make changes recommended by the Developer, then use the transition Resubmit For Development Review to send the article back to the Developer for another review. This transition will require sup_one to enter a history comment, then will move the article to the In Dev Review state and assign it to the Developer who last reviewed the article when it was previously in the In Dev Review state.

    This is implemented by:

    Transitions

    • Defining a transition to move the article to the In Dev Review state with New Assignee set to <Last Assignee for New State> with history comment set to be required

  9. State 21 - Rejected By Pubs
    Articles in this state were rejected during the review made by a Publications Reviewer. sup_one must make changes recommended by the Publications Reviewer, then use the transition Resubmit For Pubs Review to send the article back to the Publications Reviewer for another review. This transition will require sup_one to enter a history comment, then will move the article to the In Pubs Review state and assign it to the Publications Reviewer who last reviewed the article when it was previously in the In Pubs Review state.

    This is implemented by:

    Transitions

    • Defining a transition to move the article to the In Pubs Review state with New Assignee set to <Last Assignee for New State> with history comment set to be required

Sample Saved Charts

A set of sample saved charts are included in this template. Click here to see details of these sample metrics.


Email Notification

The Knowledge Base template is set up to notify users as follows:

On Add of an Article
The current assignee and the reporter of the article as well as the members of the Support Managers user group are notified

On Delete of an Article
The current assignee, the manager for the current state, and the reporter of the article are notified

On Edit of an Article
Both the current assignee, and the manager for the current state of the article are notified

On Task of an Article
The current assignee of the article is notified

On Change of State to Archived (obsolete) or Published in KB
The members of the Support Managers user group are notified


Security

The Knowledge Base template assumes a very simple security model reflecting a workgroup situation where all users are able to see any article. This is implemented by setting Enable Record Visibility option under General Preferences in the Administration Task page to No.

In addition, the privileges related to editing the field of the articles have been removed from all users that are not Admin. With this configuration, users can rely on the Task operation to move articles through the workflow. This can be changed within the User Accounts section of the Admin page.

 


NetResults Tracker © 1997-2014 NetResults Corporation. All rights reserved.