Ghost KB articles being created from Incidents

[MyrthalaF]

Hi all,

I've noticed that KB articles are being created from our resolved incidents and showing up as part of our metrics in our KB dashboard. I am not sure how to stop this from happening, they are being added to a knowledge base we don't have called Knowledge and are in a Pending-not started workflow. has anyone ran into an issue like this? 

[Vikram Reddy]

Hey @MyrthalaF,

Those aren't ghosts, they're the out-of-box Incident Create Knowledge business rule doing exactly what it's built to do. When an agent checks the Knowledge checkbox on the Resolution Information tab and the incident hits Closed, that rule spins up a draft article from the short description and resolution notes. Nobody has to open Knowledge Management for this to happen, it fires quietly off the incident record.

The part that's actually biting you is where it lands. Out of the box there's a seed knowledge base literally named Knowledge, separate from whatever KB you actually publish to day to day, and it's the fallback target whenever the platform can't cleanly resolve a default. That resolution runs through a dynamic default value on the Knowledge Base field on kb_knowledge, tied to the glide.knowman.task_kb system property. If that property isn't pointed at your real KB, or if you've got more than one record in kb_knowledge_base with Active set to true, the platform can't pick a single winner and everything falls through to Knowledge.

Start by checking kb_knowledge_base for duplicate active records, then confirm glide.knowman.task_kb holds your intended KB's sys_id. If you'd rather agents not create drafts from incidents at all, pull the Knowledge checkbox off the form or tighten the business rule's condition.

Happy to dig further if you paste the current business rule condition.

Thank you,
Vikram Karety
Octigo Solutions INC

[MyrthalaF]

Thank you for your reply. I just checked and there is no checkbox for knowledge in the resolution information tab for our agents. So I am going to check our business rule and workflow

[Tanushree Maiti]

Hi @MyrthalaF 

This is typically caused by the Knowledge check box on the Incident form  which triggers an automated business rule .

Refer: Use the knowledge check box 

KB0819409 Create a Knowledge Article From an Incident 

Create knowledge from incident or problem 

[vaishali231]

Hey @MyrthalaF 

This usually indicates that something in your instance is automatically generating Knowledge articles when an Incident is resolved. I've seen this happen due to custom automation, Flow Designer, or Now Assist, rather than standard Incident functionality.

Here are the areas I'd investigate:

1. Check Flow Designer

Review any active flows that trigger when an Incident is resolved or closed. Look for actions such as Create Knowledge Article, Create Record (on kb_knowledge), or custom subflows that generate knowledge content.

2. Review Business Rules and Script Includes

Search for Business Rules on the Incident table that reference kb_knowledge, Knowledge, or KBKnowledge. Some implementations include custom logic that automatically creates draft KB articles when an incident reaches the Resolved state.

3. Verify Now Assist / Generative AI Configuration

If your instance is using Now Assist, check whether Knowledge Article Generation is enabled. This feature can automatically create draft articles from resolved incidents, which are often placed in a default Knowledge Base and remain in a Pending or Not Started workflow until someone reviews them.

4. Check the Default Knowledge Base

Since you mentioned the articles are being created in a Knowledge Base called "Knowledge", verify whether that is configured as the default Knowledge Base. Even if your team doesn't actively use it, some automations will create articles there unless another Knowledge Base is specified.

5. Inspect the Generated KB Record

Open one of the automatically created articles and review fields such as:

1. Created By
2. Created On
3. Knowledge Base
4. Source/Reference Incident (if available)
5. Workflow/State

These details often provide clues about what created the record.

6. Check System Logs

Review System Logs or Transaction Logs around the time the article was created. This can help determine whether the record originated from a Flow, Business Rule, Scheduled Job, Script Action, or an AI capability.

7. Search for Scheduled Jobs or Workflows

It's also worth checking for Scheduled Jobs, Legacy Workflows, or Script Actions that reference kb_knowledge, as older implementations sometimes use these instead of Flow Designer.

***********************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb