×
 
 
  •  
$helper.renderConfluenceMacro('{bmc-global-announcement:$space.key}')

 

This documentation applies to the 8.1 version of Service Desk, which is in "End of Version Support." You will not be able to leave comments.

To view the latest version, select the version from the Product version menu.
Remedy Service Desk 8.1 ... Using Using BMC Service desk to manage incidents and problems Managing problem investigations Performing the analysis review

Creating a known error

If you agree with the specialist's recommendation that a change is the best way to remove the root cause of the problem, initiate the change by creating a known error and assigning it to the change coordinator of the affected service.

If  BMC Knowledge Management is installed in your environment, you can create knowledge articles to describe known errors. This information could be useful to subsequent users who encounter or analyze the same or similar issues and problems. For information about how to do this, see Recording a Known Error in a knowledge article.

To create a known error

  1. Open the relevant problem investigation as described in Viewing problem investigations.
  2. Set the Status field to Completed and the Status Reason field to Known Error.
  3. Click Save.
  4. When prompted by the system, click Yes.
    The Known Error form opens and a relationship is created between the known error and the problem investigation.
  5. In the Notes field, enter a brief description of the known error and a detailed description of the change requirements.
  6. Select the impact and urgency. The priority and weight are calculated based on the impact and urgency. If required, you can adjust the weight.
  7. Select whether view access is internal or public.
    This field is for informational purposes to indicate whether the known error is for internal or public consumption.
  8. Select the client company:
    • (Best Practice view) From the Known Error Location list, select the client company.
    • (Classic view) In the Known Error Details area of the Classification tab, select the company.
  9. From the Categorization tab (Best Practice view) or the Classification tab (Classic view), select the operational and product categorizations.
    Operational categorization is based on a three-tier hierarchy that is defined in the Operational Catalog.

  10. Ensure that the assignments are correct:

    When using the Best Practice view

    When using the Classic view

    1. Ensure that your support group appears in the Coordinator Group field.
    2. Ensure that your name appears in the Problem Coordinator field.
    3. Ensure that the Change Coordinator's support group name appears in the Assigned Group field.
    4. Ensure that the Change Coordinator's name appears in the Assignee field.
    1. Click the Assignment tab.
    2. Ensure that your name appears in the Assignee field in the Problem Coordinator Assignment area (Your name appears in this field, because you are the problem coordinator)
    3. Ensure that the Change Coordinator's name appears in the Assignee field in the Known Error Assignment area.
  11. Ensure that the known error is related to all the affected service infrastructure and to the CI in which the problem resides. For information about how to do this, see Defining relationships.
  12. Ensure that the Status is set to Assigned.
  13. Click Save.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Last modified by Bruce Cane on May 03, 2013
task creating known_error

Comments

  1. Krystian Nikolow

    Can you explain in details the meaning of View Access field? I assume that if this is a informational field there is no workflow behind, that will limit access to particular KE record based on this field value. Am I right?

    Jan 09, 2015 03:38
    1. Bruce Cane

      Hello Krystian, yes, I believe this is correct. Because the field is informaitonal, there is NO workflow attached to it. I'll double-check with our subject matter experts and confirm this with you.

      Jan 13, 2015 09:43
    1. Bruce Cane

      Hi Krystian,

      Here is what I was able to find out for you:

      "This field was used by the legacy ITSP product to limit which Known Errors were accessible to users from the ITSP Web front end (it was part of the qualification used when performing searches).  It does not prevent anyone from looking at the data as it Is not tied to permissions. 

      So right now it’s just informational. Customers can leverage it within their own customizations."

      I hope this helps. Let me know if you have any further questions.

       

       

      Jan 15, 2015 09:59
  2. Abhishek Tyagi

    Hi Team,

    Please let me know if following behaviour is as per design or its a bug?

    1. Moved The PBI in to "Completed" status with "Known Error" as status reason
    2. PKE window opens automatically and create relationships in backend as well.
    3. now if user don't save the PKE and moved back to PBI console or close the PKE window then what is the expected behaviour??

      A. PBI saved without  known error
      B. whole transaction roll-backed, PBI moved to previous status (not in completed/Known Error)
      C. system save the PKE and maintain the relationships

    Please confirm.

    Thanks,

    Abhishek 

    Apr 10, 2017 11:02
    1. Ronnie Cole

      I tried Abhishek's scenario and the PBI is saved without known error.  

      May 24, 2017 05:14

Log in or register to comment.

Reassigning the problem investigation
Reviewing known error details
© Copyright 1996 - 2018 BMC Software, Inc. © Copyright 1996 - 2018 BladeLogic, Inc.
Legal notices

Powered by Atlassian Confluence and Scroll Viewport

© Copyright 2005-2024 BMC Software, Inc. Use of this site signifies your acceptance of BMC’s Terms of Use . BMC, the BMC logo, and other BMC marks are assets of BMC Software, Inc. These trademarks are registered and may be registered in the U.S. and in other countries.