Hi,
In a typical organization, a knowledge lifecycle could be covered by several different teams (customer service representative, content authors, and content reviewers) and might look something like this:
- A customer service representative resolves a case and proposes a Draft version of a knowledge article.
- The customer Service representative submits the knowledge article for review by an approver.
- The approver approves the article, which sets the article into the Approve State.
Figure 1. The confirmation dialog for Approve command
- The publisher reviews the approved knowledge article and sets the publish date and expiration date for the article, and also specifies whether publishing should cascade to all approved translations.
Figure 2. Publish dialog options
- The publisher moves the article into scheduled state for publication.
- A system job moves the scheduled article to the Published state on the specified publishing date.
- The knowledge article is now consumable based on the permissions set.
Figure 3. Homepage grid displaying Published Articles view
- A system job moves the published article to the Expired state on the specified expiration date.
- A content reviewer moves the article to the Draft state and provides feedback on revisions needed.
A knowledge article may go through many revisions, approvals, and reviews in the lifecycle. In many cases, after a knowledge article is expired, it goes back through the process of additional approvals to be republished. This flow is depicted in the below cycle:
Figure 4. Simple lifecycle flow for a knowledge article
While this illustration is a very high-level view of the actions that take place throughout the lifecycle of an article, it does capture the essence of each stage in the process. The knowledge article may eventually reach a point where it no longer needs to be published. The knowledge article can then be archived or discarded according to business preferences.
There are two notable additions to the process of knowledge management: versioning and translations of Knowledge Articles. These are explained in more detail here:
Dynamics CRM 2016 Knowledge Article Translations
State-based modeling
Knowledge articles will be leveraging the underlying State Code concept in CRM to provide a modeling of the many states a knowledge article could be in within the Lifecycle. Below are the new state codes that are introduced as part of the knowledge article entity:
|
State Code
|
Status Codes
|
Permission Required
|
|
Draft
|
Proposed, Draft, Needs Review, In Review
|
|
|
Approved
|
Approved
|
Approve Knowledge Articles
|
|
Scheduled
|
Scheduled
|
|
|
Published
|
Published, Needs Review, Updating
|
Publish Knowledge Articles
|
|
Expired
|
Expired, Rejected
|
|
|
Archived
|
Archived
|
|
|
Discarded
|
Discarded, Rejected
|
|
Table 1. Out-of-the-box state codes and information
The above table defines the out-of-the-box status codes that are associated with each state code and denotes the special permissions required to enter a state code (if applicable). In this section, I’ll touch on the new business process flows, how to transition through the various states, and each of the state code’s intended usage scenarios.
Business process flows
The knowledge article provides two out-of-the-box business process flows that will walk users through the basic lifecycle of a knowledge article. There is one for knowledge articles, which starts at the Draft State and walks the user through the necessary stages to have a knowledge article published. You’ll notice that the Active stage of the process (depicted below) has several steps that require completion before moving to the next stage in the process. The processes are designed to help a user go through the correct steps for publishing. You can change the states by using the command bar buttons, which are explained further below.
Figure 5. New knowledge article business process flow
The second process is for knowledge articles that have expired and need to be reviewed and sent back through the lifecycle for publishing. The new knowledge article process is automatically transitioned to the expired process once the knowledge article has expired. The Process will revert to the new knowledge article process once the knowledge article has been reverted to the Draft state.
Changing states
Transitioning states from the interactive service hub is performed through the command bar buttons, which are present above the editing area. Only state transitions that are valid for the current context are presented on the command bar.
Figure 6. Where to change the state of a knowledge article
It’s always easy to know which state a knowledge article is in at a glance in the interactive service hub. Take a look at the notification bar at the bottom to see this.
Figure 7. Footer depicting current status of a knowledge article
You can also set the status reason within each state to provide more detailed insight into the current state of the knowledge article. You can do this in the header of the knowledge article form.
Figure 8. Changing the status reason for a state
Quick overview of the states
- The Draft state is where new knowledge articles are born! Proposed articles, drafts, and articles needing review are Draft knowledge articles. All newly created knowledge articles are in Draft state and require Create permissions to create a new article.
- Approved state is for knowledge articles that have been reviewed and marked as Approved. Note that one requires a special “Approve Knowledge Articles” permission to approve an article.
- Scheduled state is for knowledge articles that have been scheduled for publishing and that are picked up automatically by the auto-publish job when the publish Date/Time has reached.
- Published state is for knowledge articles that are marked for consumption either internally or externally based upon the permissions set for the knowledge article.
- Expired state is reached when knowledge articles reach their set expiration date and the desired expiration state is marked as Expired. These knowledge articles should be reviewed to determine if they need to be updated, republished, or archived based on business needs.
- Archived state is for knowledge articles that don’t currently serve a business case but have some value that should be preserved.
- Discarded state should be used for knowledge articles that are okay to delete. This serves as a symbolic recycle bin for knowledge articles to be deleted.
Roles and permissions
There is a quick callout regarding permissions that I would like to highlight. There is an entirely new Security Role added called Knowledge Manager. There are also two new permissions introduced specifically for knowledge article. Let’s look at both of these in more detail.
Knowledge Manager role
The Knowledge Manager is the security role defined for a user who is designated as the curator of knowledge management. This security role has the Create, Approve, and Publish permissions on knowledge articles for consumption. If this level of permission is not suitable for your organization’s needs, they can be tailored. Find more details on editing security roles here:
https://technet.microsoft.com/en-us/library/dn531130.aspx
Knowledge article privileges
We have also introduced two new privileges for the Knowledge Article entity, which allow for fine-tuning control over who is allowed to both approve and publish knowledge articles. By default, the Knowledge Manager role has both these privileges. In the following figure, you can see the newly introduced privileges.
Figure 9. Knowledge article privileges for the Knowledge Manager role
This role should only be assigned to users that require both the ability to approve and publish knowledge articles. Another use case for many businesses would be to define two separate security roles to effectively define a separation of privileges: one role having permissions to approve and other for having permission to publish knowledge articles.
Hope this helps!
Regards,
Venkatesh N
