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 follow 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
Manage 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
Manage 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
Manage 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. |
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. |
Publication Date |
The date the article was
published. Automatically initialized, and set
at the time the record is published as part of the workflow. |
Status* |
Current state of the
article. Changes as the record 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. |
Archive Date |
Date when the record
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 records 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
Manage Workflows section.
- 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
- 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 a record to the
Pending Pubs review state with the assignee set to be the
state manager
- Defining a transition to move a record 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
- 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 a record to the
In Pubs Review state where the assignee is the Publications
Reviewer selected by pubs_mgr during the task operation
- 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 a record to the
In Final Author Review state with the assignee set to be the
<Reporter>
- Defining a transition to move a record 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
- 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 a record 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.
- 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
- State 10 - Archived (obsolete)
This state indicates that the article contains obsolete information and
is no longer searchable in the Knowledge Base
- 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
- 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 record. 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 records have
been removed from all users that are not Admin.
With this configuration, users can rely on the Task operation to move records
through the workflow. This can be changed within the
User Administration section of the Admin page.