Minor Edits on Published Knowledge Articles

[suryapaduko]

Knowledge Versioning: Is enabling glide.knowman.versioning.enable_minor_edits a supported production approach for bulk metadata updates on published articles?

Hi Community,

I'm looking for guidance on the recommended and supported approach for performing bulk administrative updates on published Knowledge Articles while using Knowledge Versioning.

Current Scenario:

We need to perform bulk updates on hundreds of published KB Articles for metadata fields such as:

• Owned By Team
• Author
• Valid To
• Short Description
• Meta
• Type
• (Workflow State excluded, as we understand this should follow the versioning process.)

Currently, these changes require opening each published article individually because list editing is not available for published articles.

What we tested:

In our Development instance, we enabled:

1. List Control → List Edit Type = Save immediately (Cell edit mode)
2. glide.knowman.versioning.enable_minor_edits = true

This allowed inline editing from the list view for supported fields.

However, our Platform Owner has concerns about enabling this property in Production, stating that it could introduce upgrade risks in future ServiceNow releases. As an alternative, scripting has been suggested, but that would be significantly more complex for ongoing administrative maintenance.

My Questions:

1. Is enabling
   glide.knowman.versioning.enable_minor_edits considered a supported and upgrade-safe approach by ServiceNow for Production instances?
2. How does
   glide.knowman.versioning.minor_edit_fields work in practice?

• Is there a documented default list of fields?
• Can administrators safely configure additional metadata fields such as Author, Owned By, Knowledge Type, Meta, Short Description, etc.?

1. Has anyone successfully implemented this feature in Production? If so:

• Which fields are configured as minor edit fields?

• Have you experienced any issues during family upgrades?

1. From a ServiceNow best-practice perspective, what is the recommended enterprise approach for bulk metadata updates on published Knowledge Articles?

• Minor Edits?
• Custom scripting/UI Action?
• Another supported approach?

We're looking for a solution that maintains Knowledge governance and versioning while avoiding the need to manually open and update hundreds of articles one by one.

Any guidance or references to official documentation would be greatly appreciated.

Thank you!

[Eoghan Sinnott]

Hi,

We've had minor edits enabled in Production since the feature became available and have never run into a single upgrade issue with it. It's an out-of-the-box property so there's nothing there that gets overwritten on an upgrade.

On how it works: minor_edit_fields is just a comma-separated list of the field names you want editable on a published article without kicking off a new version. Out of the box the default is only valid_to. Anything you add to that list becomes editable without a checkout; anything you leave off still forces the version process.

We firmly have governance in mind with what fields we have allowed to be added to the list. We allow bulk edits on fields like Contact/Contact Backup, Valid To, Category and Topic etc. The logic is that contacts change and categorisation gets updated, and it isn't feasible to go into hundreds of articles for that kind of minor change. But things like Short Description and the actual content we keep uneditable without a checkout. For auditing it can be important to show exactly when a title or bit of content changed, and if you allow that through minor edits your reporting isn't 100% reliable without a new version.

So on your list I'd say Author, Owned By, Type and Meta are fine as minor fields, but I'd keep Short Description behind versioning.

We have had the odd case where an application name changed to a newer version and we had to manually go and update several records, but the trade-off for compliance is probably worth it.

Two things worth flagging while you test:

There's an open defect, PRB1997589, where minor edits combined with Knowledge Center and ECE redirection greys out the published article body for readers. There's an upgrade-safe update-set workaround and a permanent fix targeted for Brazil, so test for it if you run KC + ECE.

There's also an issue where the minor fields can end up editable for everyone rather than just knowledge admins/managers, so validate that after enabling.

I would go with Minor Edits as the main approach rather than scripting. It's supported and keeps you inside the KM governance model. You can then use the List Edit for any bulk edits. I'd only ruse the script approach for a genuine one-off mass correction where list editing isn't practical.

Regards, 

Eoghan

[Leri Andrews]

Minor edits is fine. Scripts have their own issues (it really messes with the ‘updated by’).  A little trick - use agent workspace and you can make bulk changes to to the minor edit fields in list view 

[BrunoPer]

Not necessarily if using autoSysFields(false).

Prevents automatic update of system fields like sys_updated_on, sys_updated_by, sys_mod_count, preserving historical timestamps. Useful for “silent” corrections