Assigning and reassigning problem investigations

A problem investigation can be assigned to an individual or a group. Use the same process to assign known errors.

To view unassigned problem investigations

1. From the Defined Searches list on the Problem Management console, run Defined Searches  > Problem Investigation  > All Open Problems. 
   For more information about running predefined searches, see Managing-custom-searches in the  BMC Helix ITSM documentation.
2. View the unassigned problem investigations in the Problems table.

To specify a problem coordinator

Problem coordinators have the functional role of Problem Coordinator within the support group to which they belong. (See Functional roles and extended application access.)

1. Open the relevant problem investigation as described in Creating-a-problem-investigation.
2. From the Coordinator Group menu, select the client company, organization, and support group that will coordinate the problem investigation. 
   After you specify the client company, organization, and support group, only the support group name appears in the Coordinator Group field.
3. From the Problem Coordinator menu, select the name of the person you want to assign as the problem coordinator.
4. Click Save.

To assign an investigation to a specialist

1. Open the relevant problem investigation as described in Creating-a-problem-investigation.

2. Indicate the appropriate assignee:

   Task	Actions
   To assign the investigation to yourself	In the Navigation pane, choose Quick Actions > Assign to Me.
   To assign the investigation based on predefined routing	In the Navigation pane, choose Quick Actions > Auto Assign.
   To assign the investigation to a specific person	Click the Work Detail tab. From the Assigned Group menu, select the support group. From the Assignee menu, select the name of the person you want to assign as the assignee. The Assignee menu displays the list of people that belong to support group you select, irrespective of the permissions they have.

3. Change the status to Assigned.
4. Click Save.

To reassign an investigation

1. Open the relevant problem investigation as described in Creating-a-problem-investigation.
2. On the Work Detail tab, explain why the investigation is being reassigned.
3. Reassign the investigation as needed:
   • To assign the investigation to yourself, select Quick Actions  > Assign to Me in the Navigation pane.
   • To let the system assign the investigation, select  Quick Actions  > Auto Assign in the Navigation pane.
     Auto Assign uses the automatic routing to assign the investigation based on predefined system mapping. Automated assignment can be based on the problem location, operational categorization, or product categorization.
   • To reassign the investigation to someone else, select a new assignee from the Assignee list.
   • To change the assigned group, select a new assigned group from the Assigned Group list.
4. Click Save.

Example of managing a problem investigation in Smart IT

Mary Mann is a problem coordinator in the Network Infrastructure group. Mary hosts a monthly incident review in which the review team evaluates incident tickets for the month and identifies recurring incidents for underlying problems with the services they are responsible for.  When the team finds an issue with a routing table for network equipment that is causing recurring incident requests, Mary begins the problem investigation process:

1. Mary locates an incident that was triggered by the problem, and on the Related Items tab, she selects Create > Related Problem Investigation.
2. The new problem investigation is populated with information from the incident, so for now, Mary updates the Investigation Driver field (a required field), and assigns the problem to a specialist. She sets the Investigation Driver to Re-Occurring Incidents. For the assignee, she clicks the pencil icon in the Assignment group. Here she has the option of having Smart IT automatically assign the best-fit group, from which she can select a specialist. However, she instead selects Bob Baxter from the Backoffice Support group, because he has the most experience in dealing with this type of problem.
3. After saving the problem investigation, Mary clicks the Share  icon and emails Bob, informing him that he has been assigned the problem investigation. She also clicks the Follow  icon so she can see updates to the problem investigation as it proceeds.
4. Mary then relates incidents to the problem investigation. She selects the Related Items tab and clicks Relate Existing Item. She searches for routing table and selects related incidents. From the Relationship Type, list she selects Related to and saves the ticket. The related items now appear on the Related Items tab.

Bob then initiates the root cause analysis. He begins by looking for a temporary workaround while he determines a permanent solution. Bob decides to review knowledge articles, where he identifies a workaround to the issue. He then updates the problem investigation ticket with the workaround:

1. In Smart IT, Bob selects Console > Ticket Console to locate and open the problem investigation. Open tickets assigned to him are displayed by default.

1. On the Resources tab, Bob finds a knowledge article that provides a workaround to the issue and pins it to the problem ticket .  
2. Bob then updates the Workaround field with a summary of the procedure and instructions to refer to the knowledge article he pinned to the problem investigation. He then updates the status to Under Investigation and saves the ticket.
3. Bob clicks the Share   icon and emails Mary to inform her that he has identified a workaround and updated the problem investigation with that information.

With the temporary workaround in place, Bob continues to investigate the root cause. He finds that the solution is to reconfigure the routing table. Before initiating the change process, Bob updates the Root Cause field:

1. Bob opens the ticket console and selects the problem investigation from the My Tickets list.
2. The Root Cause field is not visible because it contains no information. Bob clicks the pencil icon to edit the ticket and scrolls down to locate the Root Cause field. He sets the root cause to Infrastructure Issue. When he saves the changes, the field becomes visible on the ticket.
3. Bob adds an Activity Note describing the root cause. He then emails Mary to inform her that he has identified the root cause. Mary emails Bob back, letting him know that the fix requires a change request.

Now that the root cause has been identified, Mary is ready to create a related known error:

1. Mary opens the problem investigation, and under Related Items, she clicks Create and selects Related Known Error from the list.
2. Mary reviews the imported information in the Known Error form and makes any changes or additions that are needed. She then saves the known error, which subsequently appears on the Related Items tab of the problem investigation.

Mary notifies the incident review team that the root cause has been identified and that a change request will be needed to implement a structural solution. After the team evaluates the root cause, Mary creates the change request:

1. Mary opens the problem investigation and selects the Related Items tab at the bottom of the form.
2. Mary clicks the Create button and selects Related Change Request.
3. Mary completes the change request.
4. When the change is implemented, Mary updates the problem investigation status to Completed.

After the change process is complete, Mary sets the status of the problem investigation to Closed, which completes the problem investigation.