OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Knowledge Articles: Govern the Lifecycle

ServiceNow knowledge articles need a lifecycle that covers purpose, audience, drafting, review, publication, feedback, update, expiry, retirement, and ownership. The lifecycle matters because published guidance can continue directing users long after the process or service has changed.

For ServiceNow knowledge owners deciding how articles move from draft to review, publication, update, and retirement..

ServiceNow knowledge articlesarticle lifecycleknowledge publishing
Discuss this ServiceNow topic

Guide map

Turn the article lifecycle question into a repeatable review.

Define the article’s purpose and audience

Every article should have one task, one audience and one expected result.

Review evidence before publication

Confirm the owner before drafting starts, so review has someone to answer to.

Keep published content current and findable

Titles and headings should match the words users search for in the first place.

The practical framework

Govern the ServiceNow knowledge-article lifecycle from scope and drafting through review, publication, feedback, update, expiry, retirement, and ownership.

Define the article’s purpose and audience

Record the user task, intended audience, scope, prerequisites, expected result, and escalation boundary. An article should have one clear job and a reason to exist. Do not publish a broad explanation when the reader needs a specific action or request path.

The ServiceNow knowledge-management route is the relevant internal destination when article purpose and ownership need design.

Review evidence before publication

Check steps, terminology, access boundary, service or process owner, exceptions, links, images, and review date. The approver should be able to confirm that the guidance is safe for its audience and that the stated result can be understood.

The ServiceNow user-adoption route provides an internal path when published guidance supports user behaviour.

Keep published content current and findable

Use descriptive titles, terms users search, clear headings, and a visible owner. Review content after process changes, releases, incidents, feedback, access changes, or a new service boundary. Findability does not compensate for stale instructions.

The ServiceNow service-portal route is relevant when articles appear in a shared service entry point.

Use feedback and expiry as control points

Capture reports of missing steps, wrong routes, unclear language, failed use, or changed conditions. Expiry should create a review decision, not silently remove guidance that users still need. Record owner, decision, evidence, and replacement path.

The ServiceNow continuous-improvement route supports follow-up on recurring findings.

Retire content without leaving users stranded

Retire an article when its process ends, a replacement supersedes it, or its guidance cannot be made safe. State the reason and direct users to current guidance where appropriate. Preserve the decision and any remaining support need.

The ServiceNow change-management route gives an internal path when a service or process change drives retirement.

Common questions

Questions teams ask about article lifecycle

Who should approve publication?

The owner accountable for the process or service meaning should approve the content, with access, privacy, security, or support reviewers involved when their boundaries apply.

When should an article expire?

Expiry should reflect the likelihood and consequence of change, with earlier review triggered by a release, policy change, incident, feedback, access change, or service transition.

The research-grounded boundary

The design principle for a knowledge article is simple: decide what the article must prove before deciding what the platform should automate. Apply that to the lifecycle, and the boundary is only useful if a later reviewer can see what was allowed, what happened, and what remains open.

Match the Review Interval to How Fast the Answer Changes

Not every article ages at the same rate. A password reset procedure changes when the identity platform changes. A guide to requesting a laptop changes when the catalog item is renamed or the approval chain shifts. A policy summary changes with the policy. Treating all articles on one review calendar either wastes effort on stable content or leaves fast-moving content stale for months. Group articles by type before setting any interval, and record the trigger that should force an earlier review for each group.

Article typeUsual reason it goes staleReview trigger that matters mostOwner who signs the change
How-to for a self-service requestThe form, catalog item or approval route changesAny change to the linked catalog itemService owner for that request
Troubleshooting articleA new failure pattern replaces the old oneRepeated feedback that the steps did not workSupport team lead for the affected service
Policy or standard summaryThe policy text is revised or a control movesPublication of the revised policyPolicy owner, with the compliance reviewer
Known workaroundA permanent fix ships, or the workaround stops being validClosure of the linked problem recordProblem manager

Let Feedback and Search Data Open Reviews

An article’s own date tells you little about whether it is working. Usage and feedback tell you more. Searches that return the article and are followed by a support ticket on the same subject are a warning sign, as are comments that describe a step the screen no longer shows. Build the review queue from those signals rather than from the calendar alone, and let the calendar catch the articles that nobody reads and nobody complains about, because those are often the ones describing retired processes. The knowledge quality review guide covers reviewing articles for accuracy and usefulness.

  • A rising count of tickets raised after a viewer read the article.
  • Feedback that names a step, field or screen that no longer exists.
  • Search terms that find the article but lead to a different request type.
  • An article linked from a catalog item that has been changed or retired.

Where an article is meant to stop a ticket from being raised, the test is whether it resolves the incident. The knowledge deflection and incident resolution guide discusses the same question.

Replace or Retire, and Keep the Trail Intact

Retiring an article and replacing it are different acts. A replacement should keep the path users already know where practical, so that bookmarks, links from other articles and search results continue to land somewhere useful. A retirement with no successor needs a short message at the point of arrival that says what has changed and where the user goes now. Findability matters here too, because a retired article that still ranks above its replacement keeps sending people to the wrong place. The employee knowledge findability guide covers whether article titles and steps match what people ask and do. Either way, keep the old article’s record, including the reason it was retired and the owner who approved that. Without that record, the next person who finds a reference to it cannot tell whether the content was removed on purpose or lost. The knowledge management governance guide covers who owns an article and how it is reviewed.

A Review Procedure for One Article

The procedure below is designed for a single article under review, and it is short enough to run for every item in the queue.

  1. Confirm the user task the article is meant to support, and check whether the task still exists in that form.
  2. Follow the steps on the live platform as a new user would, noting each point where the instructions and the screen disagree.
  3. Check every link, attachment and related article, and confirm that each one still resolves to the right place.
  4. Decide whether the article is kept, revised, replaced or retired, and record the reason.
  5. If the article changes, have the owner approve the new text before publication and set the next review trigger.

Ownership Gaps That Leave Stale Articles Live

Many stale articles have an author who has left the team or a group that no longer runs the service. An article with no named owner is effectively unmaintained, even when it is technically published. Before any lifecycle rule can work, each article needs an owner who is a current person or role, and the knowledge team should have the authority to reassign or retire an article whose owner cannot be found. The knowledge self-service optimization page covers connecting articles to ownership, feedback and escalation.

Should an expired article be removed automatically?

Not without a review. Expiry should create a decision for the owner. Some articles remain correct well past their scheduled review and should be re-dated, while others need to be replaced before users reach a dead end.

How do we handle articles that different regions need in different languages?

Treat each language as its own article with its own owner and review trigger, and link them to a common record so that a change to the source is visible on every translation. Translation drift is one of the more common causes of conflicting guidance.

Who should approve a change to a troubleshooting article?

The support lead for the service, with a technical reviewer who has actually run the steps. An approver who has only read the text cannot confirm that the sequence works.

What do we do with articles nobody has viewed in a long time?

Check whether the task they describe still happens. Unused articles are often correct and simply rarely needed. Retire only the ones that describe a process that has ended, and record that decision.

Pick one of your most-searched articles and walk its review trail from trigger to owner sign-off before changing the review calendar.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading