Search Knowledge Button on Tasks but not Incident?

[CaitlynD]

Looking for some insight on this please. The Search Knowledge button is an excellent feature when dealing with Tasks as it seems like it grabs the whole article html and posts that so the person would receive an email with that in. 

Does the same feature exist for incidents? The Search Related Articles on an incident is good because it provides the link but it would be great to get it so that it behaved the same way and emailed it directly to them.

I have tried copying and pasting the html source code from an article into the Additional Comments field within the code markers and it works, but I only have access to the source code if the article is in draft.

Has anyone managed to alter the configuration so the Search Related Incidents grabs the whole source code please?

[GlideFather]

Hi @CaitlynD 

can you please provide screenshots for better understanding of what button?

[CaitlynD]

Of course. So I'll go through the request/task process first. So on an SCATask we have this button (comes up as Knowledge Search.

Clicking that opens up a dialog box with a search for articles that might help.

Clicking on the title opens the KB and allows you to add to the task

The code with full article html then appears in the Additional Comments (customer visible field)

Once posted it converts to pasting the whole of the article in with formatting in place. This means the customer gets an email with the same info/no need to login to the portal again to see their instructions.

On the incident side there's still an option to attach a knowledge article through the Related Search Results option.

This adds the code with just the title to the Additional Comments field

Which displays like this - which while neat and helpful and allows us to report on, is more inconvenient for the customer:

Hopefully all the screenshots have attached - have had problems before.

[GlideFather]

Ah now I see, thank you @CaitlynD for sharing the details!

For incidents, it is available only when they are Closed.

(I wanted to make a nice screenshot, so left side is an incident in Resolved state and on the Right side it's the same record in Closed state... but once you close it it changes the state in background :))) so the left side is the right side before refreshing)

And it makes perfect sense, because Request and Incident have different life cycles.

• Request is requested (optionally approved if required), then it's worked on and then it's closed. Once closed it cannot be reopened...
  • plus the relationship between REQ - RITM - SCTASK...
• Incident is first Resolved, then automatically Closed or it can be Re-opened within 7 days 
  • All the Incident state except of Closed and Cancelled are considered Active
  •  Closed and Cancelled are considered Inactive

With this being said, imagine an incident being WIP or Resolved, you create an article from it and then you realise it's not the correct resolution so that article would be inaccurate. 

So the process rather waits until it's Closed - not possible to make any changes anymore - then it allows you to use this feature.

Steps to replicate:

• create some TEST incident, regardless of the data and change all the states until you get it to Resolved and then Closed.
• that button only appears for Closed incident, not any other state.
• Note: I don't recommend to even think about changing this logics 😉

Please let me know if this makes sense for you or what would it take to consider this solved?

[CaitlynD]

Hi - it's not so much about changing the logistics as such because both these functions are available before closing/resolving the call/task. We aren't creating articles in this instance but we're attaching existing ones.

So for this it would be that on a request this might be extra information/instructions - this doesn't resolve or close that task, it's just an extra comment and it takes the whole of the html of the article and so emails it to the user.

On an incident the Related Search allows for an existing knowledge article to be cleanly linked to (rather than a messy permalink copied and pasted in), but again doesn't close or resolve anything. What I'd ideally like to do is make it so attaching the article always grabs the full html of the article.

I've tested this by just pasting the full source code in on an incident and it produces the result I want but unfortunately the only way I can see to get the source code is when an article is in draft.

So, option 1 would be to change the way that incident works so it grabs the whole thing in the same way as the sca task or option 2 find a way of getting the article source code when it isn't in draft so we can use a manual workaround/rely on humans