Should links to KB articles that have been retired still work?

[willow1]

We are on Istanbul, and have a lot of KB articles that refer and link to other articles.   We also have a lot of users that email links to articles to other users.

We noticed recently that when an article is Retired, it is still accessible through these links, and there is no indication that it is Retired.   Has anyone else experienced this?   Is this "as designed", or are we missing something in our configuration?

Our hope is that users would get something like "article not found" in this case.

Thanks for any guidance!

[Dave Smith1]

Er... ohh... that's interesting!

Yeah, I'd have thought the same thing - that setting it to "retired" would change the record active flag.   Seems the KB ignores this flag in favour of the state, I'm guessing.

Good observation... I'm going to play around with that later on.

[brianf]

There is something wrong here.   It may be in a setting or a customization.   I can tell you that when an article is retired in our system that flag is set to false. A retired article is only viewable from the backend and does not return in searches for end users (including itil, knowledge or admin roles) or if someone still has the link. You may have a customization or a conflicting ACL that is preventing a retired article from being marked inactive.

[Goran WitchDoc]

I would that is more in your instance.. I also think that a retired article should be inactive, but OOB it looks like this:

saruppaul, any ideas why articles isn't set as false when they are retired?

[Dave Smith1]

I think it's family-specific.   I've just tested this out on a Jakarta instance against KB0000002 (Email Interruption Tonight at 11:00 PM Eastern) and found:

Unticking the "Active" box meant:

• article workflow stage doesn't change to "retired"
• https://instance.service-now.com/kb_view.do?sysparm_article=KB0000002 still works (for an ITIL user)
• searching against KB0000002 found the article
• searching against Interruption missed the article (previously: hit)
• Raising an incident with Interruption in the short description missed the article (previously: hit)

Retiring the article meant:

• active remained unticked
• https://instance.service-now.com/kb_view.do?sysparm_article=KB0000002 shows "Knowledge record not found" (previously still worked in Istanbul)
• searching against KB0000002 missed the article (found in Istanbul)
• searching against Interruption missed the article (as expected)
• Raising an incident with Interruption in the short description missed the article (as expected)

I definitely think there needs to be a BR keeping "retired" and "active" in sync (or even making the active field read-only to prevent a status conflict) and the logic of including/excluding details in the search seems to involve both workflow status and active state, when it should really only use one - else this could present nebulous stages when performing scripting checks, for example.

[Sarup Paul]

We don't set the active flag based on retiring an article OOB.