Give warning message if new Request Area from Knowledge Document is not valid and cannot be updated against ticket, in CA SDM

Idea created by Kyle_R Employee on Nov 25, 2016
    Not planned
    Score4
    • GuanHua1378
    • Paul_Coccimiglio
    • Kyle_R
    • jmayer

    SUMMARY

    Provide a clearer warning message in the situation where a Knowledge Document's Category is not valid for the ticket type it is attached to, and it will therefore not be attached.

     

    Logged on behalf of client from 00480584. 

    "Accept as Solution" does not give a clear message if the ticket cannot use the new Request Area assigned from the document due to invalid ticket type I"

     

    BACKGROUND

     

    1) Set up a new Request Area called "Mobile."
    Make it available to "Incidents" but do NOT make it available to Call Requests.
    Put on a mandatory Property. (Probably optional).

     

    2) Set up a new Knowledge Category "Mobile" which references the Request Area "Mobile."

     

    3) Create a Knowledge Document under the "Mobile" Category called "iPhone error."

     

    4) Under Administration, Knowledge, Service Desk Integration, Field Mappings check both Populate empty and Overwrite Service Desk values for Problem/Incident/Request Area.

     

    5) Go to a Call Request in View mode (That is, do NOT Edit) and Search the Knowledge for the phrase "iPhone."
    The Call Request should already be saved with a Request Area EXCEPT for "Mobile" at this point.

     

    6) Right click the document that you created in (3) that is returned, and choose "Accept as Solution."

     

    RESULT

    * The Knowledge Document is Accepted as a Solution against the Call Request.
    This is correct behaviour.

     

    * The Request Area is NOT updated to the new one associated to the Knowledge Document.
    This is correct behaviour, because in (1) we did not make this Request Area available to Requests.

     

    * There is no warning message that the Request Area has NOT been updated.
    This is the concern. An Analyst may not notice that the Request Area has not been updated (correctly), but fail to go and choose a potentially different Request Area.

     

    Note - The error message introduced by patch T5PT394 does not come into play, because the Request Area was not updated. Therefore there is no failure of the new Request Areas's mandatory properties - because these are correctly never called into play.

    VARIATION 1
    * If the in "Edit" mode, then a message at the top of the screen of "Solution Accepted" appears.
    Again however, there is no warning that it could not allocate a new Request Area.

    VARIATION 2
    * This applies equally for other ticket types, such as a Request Area that is not valid for Incidents.

     

    REQUEST
    Place a warning message such as the following:

    "The new Request Area <NEW NAME HERE eg Mobile> associated with this Knowledge Document is not valid for <TICKET TYPE eg Requests>. The Request Area will be left as <OLD NAME HERE eg Email>."

     

    ENVIRONMENT
    SDM 12.9 with T5PT394 installed (mandatory). 
    Windows and SQL.

     

    BUSINESS IMPACT
    Low impact. The behaviour of not updating the Request Area is correct, given the setting of the Request Area not being available to Requests.

     

    Analysts may need to adjust the Request Area to a different one, depending on the Knowledge Document, and these may be missed.

     

    BEST PRACTICE RECOMMENDATION
    It may be a worthwhile to place the following in the patch notes, documentation or online help this best practice recommendation against the Service Desk Integration, Field Mapping section.
    "Best Practice: If using 'Overwrite Service Desk values for Problem/Incidents/Requests, it is recommended that each Request Area/Category be made available to all ticket types. This allows Knowledge Documents to be used across ticket types by 'Accept as Solution.' "

     

    WORKAROUND
    Make Categories available to all Requests, if that is where the Analysts will be attaching them.

     

    This is a standard setup and avoids the whole problem at source.

     

    This Idea is for those sites who do not wish to make Categories available to all Requests.