ServiceNow Knowledge Article Explained

What a Knowledge Article Is

A Knowledge Article is a record in ServiceNow’s Knowledge Management system. It contains instructions, solutions, or explanations that help users solve problems or understand how to do things. An article might explain how to reset a forgotten password, describe how to submit a budget request, or provide troubleshooting steps for a common software issue. Articles reduce support tickets by enabling users to help themselves and by enabling support staff to point to documented solutions.

Knowledge Articles are different from documentation stored in files or wikis. Articles live in ServiceNow, with metadata including target audience, keywords, creation and update dates, and usage metrics. The Knowledge Management system integrates with Service Request and Incident Management, so agents can search articles while handling tickets and present relevant articles to users as suggested solutions.

Where Knowledge Articles Live

Articles are organized in a Knowledge Base, a collection of articles on similar topics. A “Software” knowledge base might contain articles about installed applications. A “Network” knowledge base contains network-related content. Articles have titles, keywords, and category tags that make them discoverable. Users search for articles using keywords; ServiceNow ranks results by relevance and popularity.

Articles have metadata affecting visibility. A draft article is visible only to authors; published articles are visible to your target audience. An article marked as not visible hides it from the public interface but keeps it available to support staff. Expiration dates let you automatically archive outdated articles. Knowledge managers review metrics on how often articles are used to identify which topics need better coverage.

A Worked Example

Your helpdesk receives dozens of calls each week from users who have forgotten their passwords. You create a knowledge article titled “How to Reset Your Password” with steps for the self-service password reset process. You tag it with keywords: password reset, forgot password, locked account. You mark it as published so all users can find it.

Now, when a user calls about a forgotten password, the agent can send them a link to the article. Many users read the article, reset their password, and never need to call. Those who call see the article in an email. Your helpdesk deflects dozens of tickets per week to self-service. The time spent writing the article is paid for by the hours of support staff time it saves.

Your IT team also uses the article internally. When covering for the primary password reset specialist, a team member can reference the article to ensure they are following the right steps. New team members learn the process from the documented steps instead of requiring training from a busy colleague.

Knowledge Integration with Incident and Request Management

When an agent is handling an incident or request, they can search the Knowledge Base without leaving the ticket. If an article matches the customer’s issue, ServiceNow can automatically suggest it to the customer. Knowledge articles linked to incidents help document solutions so future tickets with similar issues can reference existing solutions.

Knowledge metrics show which articles are used most often, which articles solve problems completely versus those where customers still need support, and which topics have no articles. These metrics guide investment in knowledge creation. Topics with high search volume but no articles indicate content gaps. Topics with published articles but low usage indicate either poor discoverability or content that does not match user needs.

Knowledge Management and Maintenance

Articles require maintenance. Procedures change, systems get updated, outdated articles create confusion and support calls. Most organizations assign a knowledge manager to review published articles quarterly, retiring outdated content and updating procedures that have changed. Ownership assignments ensure someone is responsible for keeping each article current.

Articles should be written clearly in language your audience understands. Overly technical articles are useless to business users; overly simplistic articles waste time for experienced users. Screenshots and step-by-step instructions are more useful than conceptual descriptions when users need to do something.

Deciding whether a question deserves an article at all

Most knowledge programs start by writing too much. Every repeated ticket looks like a candidate, and a team tired of answering the same question will draft an article on a Friday afternoon and call the job done. The harder decision is whether an article is the right container. An article suits a stable procedure read by someone with a few minutes to spare. It is a poor carrier for a workaround that changes every month, for a decision that needs an approval, or for a request that should be submitted rather than explained.

Before drafting, settle three things: who opens the article, what state they are in when they land on it, and what they must do in the next two minutes. A blocked and frustrated user needs the first step on screen before any background. A person following a procedure needs numbered steps they can keep beside the application. An agent pasting a link into a ticket needs a title they recognize in the search results without opening the article first.

Building a review path that people will actually follow

A publishing path that takes too long gets bypassed. Agents start pasting steps into chat, and the organization ends up with a second, unofficial library that nobody can audit. The usual remedy is a path with two lanes: a fast lane for corrections to an existing article, and a full review for new content or for anything touching access, money or personal data.

1. Name an owner for each knowledge base before anyone writes into it, and record that owner on every article.
2. Require the writer to complete the audience, the outcome the reader should reach, the related services and the date the steps were last run end to end.
3. Have a second person follow the steps on a clean test account, not on the machine where they were written.
4. Route access, finance and security content to a reviewer who did not write it.
5. Publish to the intended audience only, then check the first week of search terms against the title and keywords.
6. Set a review date that matches how often the underlying screens change, and expire any article that describes a screen a vendor is about to replace.

Where article programs usually go wrong

• Titles written as internal project names, so searchers rarely find them for the symptom they have.
• Articles that describe a feature instead of a task. They read well and solve nothing.
• Vendor documentation pasted in without adjusting it to local screens, approval rules and naming.
• Visibility left at its default, so internal troubleshooting notes reach end users.
• Duplicates created because the search box did not surface the existing article under a different word.

The last failure costs the most over time. A library that grows by duplication forces agents to choose between near-identical articles, and each choice carries a small chance of a stale answer. Merging duplicates is slower than writing something new, but it is the work that keeps the library trustworthy.

Reading the signals that show an article is working

A high view count proves less than it seems. An article viewed constantly may be the only option people have found, because the real answer is missing. Read the signals together. Searches that return nothing point to missing content. Searches that return an article nobody opens point to a weak title or a keyword that does not match how users describe the problem. Views followed by a new ticket on the same topic point to an article that stops short of finishing the job. Feedback ratings help only when someone reads the comments that come with them.

Set the thresholds from your own baseline for each signal. The acceptable rate for a service desk handling payroll questions is not the right rate for a team publishing architecture notes, so resist importing a figure from another organization and treating it as a target.

Retiring, merging or rewriting an article

Retirement is the decision teams often postpone longest. An article that was accurate before the last platform change still ranks in search and still gets pasted into tickets. Put a retirement step into the review path: when an article is replaced, the old one points to the new one for a defined period, then moves out of the public audience. Rewrite when the steps still hold but the explanation confuses readers. Merge when two articles answer the same question for different readers and the only real difference is the opening paragraph.

Questions teams raise once the program is running

Should one article cover several devices or should each device have its own?

Split by the task a reader is doing, not by the device. One article can cover a procedure that differs in two or three small steps, provided each variant is labeled clearly. Once the variants diverge in most of their steps, separate articles are easier to keep correct.

Who should be allowed to publish without review?

Authors who have had their first few articles reviewed closely can publish corrections directly. New authors, and anyone writing about access, finance or security, should go through review. The rule follows the risk of the content, not the seniority of the writer.

Agents link one article from many tickets, but users rarely open it. What is going on?

Agents reach for it because it is the nearest match they know about. That usually means the user-facing title uses the wrong words, or the article is written for an agent when the reader is the requester. Retitle it in the words users type, check the audience setting, and compare the opening paragraph with what the agent is trying to tell the user.

Can a knowledge article stand in for a catalog item?

Only when the request is rare enough that building a catalog item is not worth the effort. If the same request arrives every week, the article becomes an extra step between the user and a form, and the form is almost always the better experience.

Where to start if the library has grown without owners

When a knowledge base has grown without named owners, the first piece of work is an audit of what is published, followed by the review path above. Retire the duplicates and the expired screens before writing anything new, because new articles added to a cluttered library rarely get found.

Deflection is the outcome most sponsors want, so tie the work to it. The guide on knowledge deflection and incident resolution covers how accurate guidance can support faster resolution. For the related service, see the knowledge and self-service optimization page.