Adjusting the Knowledge "Attach" button in Incidents

[MaxB43973023201]

Hello,

How do you guys do to know if an Knowledge article has been used to resolve an incident/ticket within SN? I handle Knowledge for an IT Service Desk and we have alot of Knowledge that should only be seen by our Service Desk and not end-users. If we use the "Attach" button in the incident it would send it to the end-user whilst it may not be available to them or anything relevant for them.

In one of our test environments, I have experimented with modifying the setup so that the article URL is no longer embedded into the additional comments field for the end-user. However, we still aim to utilize this "Attach" button to be able to send articles to end-users, when it's available and suitable but this would not be possible if we do this change.

I think what I am looking for would be something like this:

Clicking attach asks you if you want to attach it and send it to the end-user OR ask if you want to only attach it without sending Knowledge to end-user.

Generally just curious to know how people do. We're trying to work with KCS so every incdient should have an Knowledge article attached and if not, then one should be created or a knowledge gap should be reported.

[Its_Azar]

Hey there @MaxB43973023201 

So when it comes to managing knowledge articles within ServiceNow, especially in relation to incidents, One common concern, as you've pointed out, is how to handle knowledge articles that should only be accessible to the Service Desk team and not to end-users.

First, you can restrict access to knowledge articles based on roles or groups, ensuring that only authorized users can view or access them. Additionally, maintaining separate knowledge bases or categories for different audiences can help control visibility more effectively.

Regarding the "Attach" button behavior in incidents, customization might be necessary to prompt users whether they want to attach an article and send it to the end-user or attach it without sending it. This customization would likely involve scripting and UI policy configurations.

Implementing approval workflows for knowledge articles can also be beneficial. This allows users to initiate an approval process to review whether the article is suitable for end-users before it's sent out, ensuring that only relevant information is shared.

Hope this helps!, Kindly accept the response if it did thanks much.

[Tam_Mailley]

There is a function available where you can add a radio button that allows you to view as user. This allows knowledge to be searched that is available for the end user, based on their role.

So if your attaching any resolution process you'll know they can see it and access it. 

[Mike Van Vooren · Accepted solution]

For us, we made 2 adjustments.  The first is that we switched which notes the attaching occurs with.  Instead of the OOB way of attaching to External (Customer) notes, we have it attach to Internal (Work) notes.  That ensures that none of the Callers can see the article attached by default.  The 2nd adjustment we made was a new button on the Incident form called "Share KA".  If the Incident Worker knows the article is End User facing and might have some information to help self-solve their issue, they can choose to click the button.  That would then add an External (Customer) note and trigger an email to the user with a link to the article.  As was mentioned earlier, it doesn't stop the Incident worker from sharing an IT article they do not have permission to see.  The only thing I don't like about this part of the solution is that we can't track how often the "Share KA" button is used.

[MaxB43973023201]

This is pretty much what I want aswell.

This Share KA button is that tons of OOTB scripting/configurations? 🙂