Knowledge and catalog items

[diwanex]

How can I connect the dots between a record producer used to capture knowledge article updates and have those updates automatically update the associated knowledge article? 

[Anupam1]

Hi @diwanex ,

To bridge record producers (which capture input from users in ServiceNow) with knowledge articles so that updates flow automatically:

 Key Concepts

• Record Producer: A type of catalog item that creates records in a table (often Incident, Change, or a custom table).
• Knowledge Article: Stored in the kb_knowledge table, with fields like short_description, text, category, etc.
• Goal: When someone submits a record producer form to suggest or update knowledge content, the associated knowledge article should be updated automatically.

How to Connect the Dots

1. Identify the Target Knowledge Article
• Add a field in the record producer (e.g., a reference field to kb_knowledge) so the user can specify which article they’re updating.
• Alternatively, use logic to determine the article based on category, keywords, or a mapping table.
2. Capture Update Data
• Record producer variables (like “Updated Content,” “Correction,” “Additional Notes”) will hold the new information.
• These variables are stored in the generated record (often in a staging/custom table).
3. Business Rule / Flow Designer
• Create a Business Rule or Flow Designer Flow on the target table (the one the record producer writes to).
• Logic:
• On insert/update of the record, fetch the associated knowledge article (kb_knowledge).
• Update the relevant fields (e.g., text, short_description, attachments).
• Optionally, set the article back to a “Draft” or “Review” state for approval before publishing.

Example (Business Rule pseudocode):

(function executeRule(current, previous /*null when async*/) {

    var kb = new GlideRecord('kb_knowledge');

    if (kb.get(current.kb_article)) {

        kb.text = current.update_text;

        kb.short_description = current.update_summary;

        kb.update();

    }

})(current, previous);

1. Approval Workflow (Optional but Recommended)
• Instead of directly updating the article, route the update through a workflow:
• Create a “Knowledge Update Request” record.
• Assign to knowledge managers for review.
• Once approved, the workflow updates the article.
2. Audit & Versioning
• Knowledge articles have versioning built in. Ensure your automation respects this:
• Either create a new version when updating.
• Or log the update request in a related table for traceability.

Best Practice

• Don’t overwrite articles blindly. Route updates through a controlled process (Flow Designer or Workflow) so knowledge managers can approve.
• Use Catalog Item Variables smartly. Map them directly to knowledge fields.
• Maintain traceability. Keep a record of who suggested the update and what changed.

 In short:
Use the record producer to capture update requests → store them in a staging table → trigger a Business Rule or Flow Designer action → update the associated knowledge article (either directly or via approval workflow).

If my response helped please mark it correct and close the thread so that it benefits future readers.

Best,

Anupam.

[GlideFather]

Hi @diwanex,

can you better explain the use case? What dots are you talking about? If you have a record producer to capture article updates then it must be a custom logics, thus it's difficult to help you without knowing details...

The KB Articles shall not be automatically updated, they usually have an owner or an owner group who are responsible for the content, which has validity and versions. Making it freely updatable might not be the best idea... 

[diwanex]

Here is the scenario- 

The intakes submitted on the record producer are managed by a content team who desire that the updates requested flow into the aligned kb #s so that it is not as manual as it is today to flip through the request and the article itself. The updates would still flow to the aligned ownership group once the requests have been updated. Hope this helps.