Knowledge Management is the ITIL practice of collecting, organizing, sharing and maintaining knowledge so that the right information reaches the right people at the right time.

Its main objective is to improve decisions and speed up resolution by making knowledge easy to find and reuse, instead of it living in a few people's heads.

In ServiceNow, articles live in the kb_knowledge table, grouped into Knowledge Bases and categories. They reach people through the agent workspace, the Service Portal, Virtual Agent and search.

Why it matters: fewer repeat tickets through self-service, faster resolution at L1 with documented workarounds, knowledge kept when people leave, and quicker onboarding.

Note: Tie it to business outcomes in the interview. Every article that deflects a ticket saves agent time, which is why Knowledge Management is one of the cheapest ways to scale support.

A Knowledge Base is a container that groups related knowledge articles. It defines who can read the articles, who can write them, which approval workflow is used and how articles are categorized. Each one is a record in the kb_knowledge_base table with its own owner, managers and categories.

Yes, an instance can have many, and most enterprise instances do. Typical examples are an IT knowledge base, an HR knowledge base, a customer support knowledge base, and restricted ones for security or compliance.

Reasons to separate them: different audiences need different access, each base can have its own approval workflow and owner, and reporting can be done per base.

Note: Too many knowledge bases is as bad as too few. If users have to search many bases to find an answer, adoption drops.

1. Draft: the author writes the article. It is not visible to readers yet.

2. Review: the article is submitted and approvers (a knowledge manager or SME) check its accuracy.

3. Published: approved and visible to the readers allowed by the knowledge base's user criteria.

4. Outdated or flagged for review: when an article is reported as wrong or stale, it goes back for review.

5. Retired: no longer relevant. It is hidden from readers but kept for audit and history.

The transitions are driven by the knowledge base's workflow (for example, the approval-and-publish workflow). When a published article is updated, a new version is created under the same article number, and readers only see the latest published version.

Both control access to a knowledge base, at different levels.

Can Read: who can find and read published articles. Example: everyone in the company can read the IT knowledge base.

Can Contribute: who can create and edit articles. Example: only the IT support groups can write in the IT knowledge base.

A user matching any of the listed criteria qualifies, and "Cannot Read" criteria override "Can Read" (for example, to exclude contractors). Example for an HR confidential base: Can Read for HR and leadership, Can Contribute for HR managers, Cannot Read for contractors.

Note: User Criteria are not ACLs. Saying "we restrict knowledge with ACLs" is a common mistake in interviews.

With versioning, ServiceNow keeps every published version of an article. The article number (for example KB0010025) stays the same, but each version is its own record.

How it works: you check out a published article, which creates a new draft version. Readers keep seeing the current version while you edit. When the draft is approved and published, it becomes the live version and the old one is kept in the version history.

Why it matters: an audit trail of what guidance was live on a given date, the option to go back to an earlier version, and the ability to compare what changed. Regulated industries often require this.

kb_knowledge_base: the knowledge bases, with their owners, managers, workflows and user criteria.

kb_category: the category tree inside each knowledge base.

kb_knowledge: the articles. Key fields are number, short_description, text, kb_knowledge_base, kb_category, author, valid_to and workflow_state (draft, review, published, outdated, pending retirement, retired).

kb_use: article views, used for "most viewed" and usage reports.

kb_feedback: ratings, helpful votes and comments from readers.

m2m_kb_task: links articles to the incidents and other tasks they were attached to, which shows which articles actually solve tickets.

user_criteria (with the knowledge base's Can Read and Can Contribute lists): who can read and who can write.

Here the content exists but nobody uses it, so the fix is part technology and part habit.

1. Find out why users skip it: they may not know it exists, search may return poor results, or raising a ticket may simply feel faster.

2. Search before submit: on the portal, suggest matching articles while the user types the short description, so they find the answer before submitting.

3. Make search the main entry point on the portal, with "create a ticket" as the second option.

4. Improve quality: retire outdated articles, rewrite unclear ones, and add the words users actually use as keywords.

5. Add Virtual Agent so common questions are answered from articles before a ticket is raised.

6. Measure deflection (tickets avoided, article views, helpful ratings) and keep improving.

The goal is to turn one person's know-how into shared knowledge.

1. Capture it at resolution: the agent creates a knowledge article from the incident (Create Knowledge), which pre-fills the short description, the resolution details and a link to the incident, so the agent only has to tidy it up.

2. Review: the draft goes through the knowledge base's approval, for example an SME for accuracy and the knowledge manager for clarity.

3. Publish and share: once published, notify the relevant support group so agents know about the new workaround.

4. Reuse: similar incidents will now show the article as suggested knowledge, so agents don't have to remember it.

5. Encourage it: track articles created per agent and recognize good contributors.

Why sys_id links fail: each version of an article is its own kb_knowledge record. The article number (for example KB0010025) stays the same, but every published version gets a new sys_id. A link such as kb_view.do?sys_kb_id=<sys_id> keeps pointing at the version it was created for, so after the next publish readers land on an outdated version, or see "article not found" if they can no longer view it.

Link by article number instead. It never changes, and both of these open the current published version that the reader is allowed to see:
- Service Portal: /sp?id=kb_article&sysparm_article=KB0010025
- Platform UI: kb_view.do?sysparm_article=KB0010025

In scripts, look the article up by number and published state, not by a stored sys_id:

function getPublishedArticle(number) {
    var articleGr = new GlideRecord('kb_knowledge');
    articleGr.addQuery('number', number);
    articleGr.addQuery('workflow_state', 'published');
    articleGr.setLimit(1);
    articleGr.query();
    return articleGr.next() ? articleGr : null;
}

// Example: a notification mail script that links to the live version of an article
var articleGr = getPublishedArticle('KB0010025');
if (articleGr) {
    var url = gs.getProperty('glide.servlet.uri') + 'sp?id=kb_article&sysparm_article=' + articleGr.getValue('number');
    template.print('<a href="' + url + '">' + articleGr.getValue('short_description') + '</a>');
}

Where to store references: keep the article number in custom fields, catalog variables, Virtual Agent topics and external systems. A reference field to kb_knowledge points at one specific version, so either store the number or resolve it to the published version when you display it.

When the version sys_id is right: Attached Knowledge on an incident (m2m_kb_task) deliberately records the exact version the agent used, which is what you want for audits.

Note: Interviewers ask this to see whether you understand knowledge versioning. "Link by number, never by sys_id", plus the portal URL format, is the key point.

Advanced User Criteria run a script that returns true or false. You don't declare user_id yourself: when ServiceNow evaluates the criteria it provides user_id to the script, holding the sys_id of the user being checked. That is why it looks undefined if you paste the script into a background script.

checkCondition();

function checkCondition() {
    // user_id is provided by the platform: the sys_id of the user being evaluated
    var userGr = new GlideRecord('sys_user');
    if (!userGr.get(user_id)) {
        return false;
    }
    return userGr.getValue('active') === '1' &&
        userGr.getDisplayValue('department') === 'Finance';
}

Why user_id: user criteria results are cached and can be evaluated for a user other than the one logged in (for example, when an admin checks access or a job runs). gs.getUserID() returns whoever is running the script, so the result can be wrong or cached for the wrong person.

Note: Prefer the declarative fields (roles, groups, departments, companies) when they are enough. Use a script only for rules they can't express, and keep it fast, because it runs very often.

Four pieces work together:

1. A Scheduled Script Execution that runs once a day.
2. An event registered in the Event Registry, for example kb.article.expiring on kb_knowledge.
3. A Notification on kb_knowledge that sends when that event fires, with "Event parm 1 contains recipient" ticked.
4. The script, which finds published articles whose Valid to date is exactly 7 days away and fires the event for each, passing the author as parm1:

var articleGr = new GlideRecord('kb_knowledge');
articleGr.addQuery('workflow_state', 'published');
articleGr.addQuery('valid_to', '>=', gs.daysAgoStart(-7));
articleGr.addQuery('valid_to', '<=', gs.daysAgoEnd(-7));
articleGr.query();
while (articleGr.next()) {
    // parm1 = who gets the email, parm2 = the expiry date for the message
    gs.eventQueue('kb.article.expiring', articleGr, articleGr.getValue('author'), articleGr.getValue('valid_to'));
}

Because the job runs daily and checks a one-day window, every owner gets exactly one reminder. Firing an event instead of sending email from the script keeps the wording editable and every email in the log.

You can write and run this script on practice data in the sandbox on Scenario Based Scripting.

Use the Knowledge Management REST API (namespace sn_km_api) for reading and searching, for example GET /api/sn_km_api/knowledge/articles?query=vpn. It returns only published articles, applies the knowledge base's user criteria for the calling user, and ranks results like knowledge search does.

The Table API on kb_knowledge (/api/now/table/kb_knowledge) reads raw records. It doesn't apply knowledge search or user criteria the same way, so it can show drafts or restricted articles if the integration user has wide access. Keep it for admin-style work such as bulk imports or migrations, run by a tightly scoped integration user.

Note: Call the API as the end user (or pass their identity) when access matters, otherwise every reader effectively gets the integration user's access.