Knowledge Base Article Version Trimming

[scottlarson]

I am still pretty new to the platform, but I met with an IT business partner who has identified issues with certain articles with high version numbers (40+) containing attachments taking much longer to load than normal. It was unclear whether the attachment size or number of attachments is the culprit. 

This conversation led me to the issue of version trimming. We don't need to keep every article version ever created since that introduces ROT (Redundant, Obsolete, Transitory) data that could create more issues than it solves. Does ServiceNow have the ability to designate how many version should be kept in archive before trimming? Or has anyone created a process outside of ServiceNow to serve the same function?

Thank you.

[Kim27]

Hi Scott, based on a quick review, a business rule can be created to limit the number of article versions retained. However, I suspect the issue with such a robustly edited article is the number of attachments. See this post. It discusses that when images in the body of knowledge articles are deleted, the attachment remains and how this company solved for the issue:   Over your storage limits? Wrangling in Knowledge ... - ServiceNow Community

You might want to review the number of attachments for the article loading so slowly. 

[scottlarson]

Thank you, Kim27. I'll review this with my team to see if it solves our issue!

[Arnaldo]

HI Scott
The low performance due to the number of releases of an article is new to me, but I am interested in understanding how you managed to measure this performance difference.
In any case, I believe that the information you provided is very relevant, especially when associated with the generation of translations.

We have already experienced negatively the possibility of archiving obsolete articles, which caused issues with managing translations.

In fact, if the first version of the knowledge article is archived, all references with the translations are lost. The sysID of the first version is the one used in the article ID of all versions, and by archiving it, all references are lost. I suggest creating an IDEA that I will definitely vote for, in the hope of an implementation.