Over your storage limits? Wrangling in Knowledge articles
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-03-2023 08:26 AM
This is a continuation of the mini-series "Over your storage limit? Reducing our storage footprint; our lessons learned."
This post is about some extra steps we took to keep our knowledge articles under control. Including deleting unused images, deleting attachments past a certain age/version, and deleting minor article versions.
Wrangling the knowledge space proved to be difficult because it was really hard to guess user intent in some situations.
Disclaimer:
This post is about the deletion of records to reduce the storage footprint size at our company. This is what worked for us and it may not work for you. Know your policies and retention periods and as always, review and make sure you test everything in a sub-prod instance first.
Remove unused images from knowledge articles
Images in knowledge articles are added as attachments. If I have an image in a knowledge article's body, then I delete the image from the body, what happens to the attachment? Nothing. It is expected that the user would be removing it. And, well, they don't.
What was their intent with the image to begin with? Replace it with another image? Move it somewhere else in the body? Keep it as something users could download instead?
We found the majority of images on knowledge articles that weren't currently used in the body, had previously been used in the body and the attachment was left behind. People would have an image in the article's body, then deleted it, but never delete the attachment (and why would they?). That "deleted" image still sitting there became a HUGE problem once we enabled versioning.
After getting stakeholder buy-in, my cohort wrote a business rule that spot checks for abandoned images when an article changes from Draft. It looks at all image/video attachments on the current record and checks to see if the sys_id of the attachment is in the body. If it isn't, it removes it from the record.
We don't run this if Display attachments is true. If it is true, we assume someone wants to share an image or video file for someone to download, so it may not intentionally be in the article's body.
When to run: after
Updated: true
Filter conditions: Display attachments is false AND Workflow changes from Draft.
(function executeRule(current, previous /*null when async*/) {
// Get list of attachments on current knowledge article
var att = new GlideRecord('sys_attachment');
att.addEncodedQuery('content_typeSTARTSWITHimage/^ORcontent_typeSTARTSWITHvideo/^table_name=kb_knowledge^table_sys_id=' + current.sys_id);
att.query();
// Iterate through attachments related to current KA
while(att.next()){
// If the attachment sys_id is not found within the KA body
if(current.text.indexOf(att.sys_id) === -1){
// Delete the attachment
att.deleteRecord();
}
}
})(current, previous);
Remove attachments from old knowledge versions
Every time a knowledge version is created, it creates copies of all the attachments on it. SN does this so if you revert to a previous version, it has all the correct attachments for that version. This also becomes a huge mess because of people deleting images from the article's body, but not removing the attachment (the above scenario).
We made a blanket statement that "all attachments will be removed from articles starting at version 50 and older" (we picked 50 because we had some trouble getting buy-in from some process owners. We wanted to do 20).
If an article turns over to version 51, we go all the way back to version 1 and delete any attachments from it. Or if an article turns over to version 74, we go back to version 23 and delete from that.
We are doing this via a business rule that only goes back to the one version and deletes the attachments. We also put in an option to exclude some knowledge bases.
We did write a 1-time script to run to go back and clean up everything previous to version 51 (a script that I do not have, sorry). This business rule is just to maintain (we shouldn't have to look at so many previous copies each time).
When to run: after
Insert: true
Update: true
Filter conditions: none
(function executeRule(current, previous /*null when async*/) {
//If you want to exclude this from running against a specific knowledge BASE, put the sys_id of the knowledge base into the excludedKBs string.
// Example: 'fc2a353edba11c188ef03533f39619b4 , f85edde087fc611c98cbc91e0ebb35fd';
var excludeKBs = '05e6a03a1bcc30107917caab234bcbda, 40c84ccddbfbe01026c4b3b2ba96196b';
var verToKeep = '50'; //The number of versions back to keep. Anything before this will have attachments removed. Yes, this needs to be a string. Example: '5' for 5 previous versions before deletion or '11' for 11, etc.
//If the article is not in a KBase being excluded, continue.
if(excludeKBs.indexOf(current.kb_knowledge_base) === -1){
// Get KA version number based on above configured value
var oldVerNumber = (current.version.version - verToKeep) + '.0';
// Look up knowledge article for old KB based on calculated version number
// This should always return one record
var oldVerRecord = new GlideRecord('kb_knowledge');
oldVerRecord.addEncodedQuery('number=' + current.number + '^version.version=' + oldVerNumber); //
oldVerRecord.query();
if(oldVerRecord.next()){
// Look up attachments associated with the above knowledge article and delete them
var oldAttach = new GlideRecord('sys_attachment');
oldAttach.addEncodedQuery('table_sys_id=' + oldVerRecord.sys_id);
oldAttach.deleteMultiple();
}
}
})(current, previous);
Delete previous minor versions
We haven't started work on this this one yet. I'll update this section when I have more information.
Our records retention department (make sure to check with yours!) told us that minor versions could be deleted because the intended audience never had access to it. We will use another business rule when an article changes to published or retired, to delete the minor versions of the article, except for the most recently published one.
- 745 Views
