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. 

[Anupam1]

Hi @diwanex ,

Here’s a end‑to‑end Flow Designer blueprint you can use:-

 The exact steps, actions, and mappings needed to automate the intake → KB update → ownership review process.

Record Producer → Knowledge Article Updates:

1. Record Producer (Catalog Item)

• Variables:
• kb_number (Reference to kb_knowledge)
• update_summary (Short description of the requested change)
• update_text (Rich text field for corrections/additions)
• attachments (Optional file upload)
• reason_for_update (Dropdown: typo, correction, new content, etc.)

• Target Table: Custom table u_kb_update_request (staging table for audit trail).

2.   Flow Designer: Knowledge Update Automation

    A.   Trigger

• Table: u_kb_update_request (custom staging table populated by the record producer)
• Condition: State = Ready for KB Update

    B.  Flow Steps:

Step 1: Get KB Article

• Action: Get Record
• Table: kb_knowledge
• Record ID: current.kb_number (reference field from the request)

Step 2: Update KB Article

• Action: Update Record
• Table: kb_knowledge
• Fields to update:
• short_description = current.update_summary
• text = current.update_text
• Attachments = copy from request (use Copy Attachments action)
• Set State: Draft (forces review before publishing)

Step 3: Create Version (Optional)

• Condition: If current.reason_for_update = Major Rewrite
• Action: Create Record
• Table: kb_version
• Fields: Link to KB article, copy text, mark as new draft version

Step 4: Notify Ownership Group

• Action: Create Task
• Table: sc_task (or custom task table)
• Assignment Group: kb_knowledge.ownership_group
• Short Description: “Review KB #${kb_number} update”
• Description: Include:
• Link to KB article
• Link to original request
• Summary of changes applied

Step 5: Update Request Record

• Action: Update Record
• Table: u_kb_update_request
• Fields:
• State = Applied to KB
• Assigned to = kb_knowledge.ownership_group
• Resolution Notes = "Changes applied to KB #${kb_number}, pending ownership review"

1. Governance Flow

• Ownership group reviews KB article in Draft state.
• Approve → KB article moves to Published.
• Reject → Request reopens for content team.

    2.   Audit & Reporting

• All requests remain in u_kb_update_request for traceability.
• Dashboards can show:
• Pending requests
• Applied updates
• Ownership group workload

Benefits

• Content team no longer flips manually between requests and KBs.
• Updates flow automatically into the correct article.
• Ownership group retains governance.
• Audit trail preserved for compliance.

This is the exact Flow Designer sequence:
Record Producer → Staging Table → Flow Designer → KB Article Update → Ownership Group Review → Publish.

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

Best,

Anupam.