Service Request Linking to Specify Duplicates and Other Relationships

This chapter covers the following topics:

Overview of Service Request Linking

By creating a relationship link with another service request or to another object, such as a maintenance plan for a piece of equipment, agents can make information available with a mouse click.

Relationships indicate, for example, that one service request is a duplicate of the other, that one is the cause of another, or that it contains relevant information for the resolution of another. An individual service request can be linked to multiple other objects.

Some types of relationships are merely informational. Others propagate the change of status in one service request to other service requests linked with it. For example, if agents specify that service requests A and B are caused by service request C, then closing C closes A and B as well.

Note: Status propagation is available only for linked service requests, not for other E-Business Suite objects.

The breakdown of a major system can sometimes cause multiple customer contacts to report the same problem. The status propagation permits the service organization to deal with all the duplicate service requests all at the same time.

Users have six available relationship types for linking service requests to other service requests:

Only the last two relationship types can be used to link service requests to other objects you set up:

Because relationships between two objects are bidirectional, they come in pairs. If a user specifies a relationship in one direction, the application automatically specifies a relationship in the other direction:

The following two relationship pairs also propagate status changes between the linked service requests:

The following table explains the three most frequently used relationship types. The Action column of this table indicates both the status changes and reciprocal links created automatically by the application.

Relationship Action Example
Caused by Linking service request A to service request B using a “Caused by” relationship indicates that A is caused by B.
The application:

  • Sets the status of A to “Waiting”.

  • Creates the reciprocal link “Root Cause of” for B.


When B is set to the status of “Closed”, then the status of A is automatically set to “Clear”.
If multiple service requests are “Caused by” B, then all are set to “Clear”.		 Problem:
A customer contact calls to say his e-mail is not working. The support agent discovers that the system administrator has already logged a service request to track this problem. The contact's e-mail is not working because the e-mail server is down.
Resolution:
The agent creates a “Caused by” link between the contact's service request and the service request already logged for the e-mail server problem. The application automatically sets the status of the contact's service request to “Waiting”.
When the system administrator resolves the e-mail server failure and closes the server problem service request, then the application automatically updates the contact's service request status to “Clear”.
Duplicate of Linking service request A to service request B with the “Duplicate of” relationship indicates that A is a duplicate of B.
The application automatically:

  • Creates an “Original for” link from B to A.

  • Changes the status of A to ”Closed” with the resolution code “Closed as Duplicate”.

 All call center agents have been notified of the e-mail outage. Subsequently, an employee logs a ticket to report the e-mail outage.
The agent who is assigned to work on the service request identifies it as a duplicate and enters the “Duplicate of” link.
The application automatically closes the employee's service request with the resolution code of “Closed as Duplicate” and a reference to the service request already logged for the e-mail outage.
Refers to If service request A “Refers to” service request or document B, this means that B has information relevant to A.
The application automatically creates the reciprocal “Reference for” relationship from B to A provided both documents are service requests.
Agents can use this type of relationship for linking a service request to another object, such as a maintenance plan. See "Adding Reference Links to Objects Other Than Service Requests" for more information.		 An agent working on a service request remembers that he created a similar service request for another customer. By creating a link to that old service request, he makes it possible for others to refer to it.

Note: Agents are permitted to indicate service request A is a duplicate of service request B only if service request A has no existing relationship links of type Duplicate of, Original for, Root Cause of, and Caused by. The service request may have existing relationship links of type Reference for and Refers to. If A does contain links, and agents wish to indicate A is a duplicate of B, they must first remove the links from A.

Agents are restricted in this way for logical reasons:

Note: If you are using status groups as described in Status Groups and Status Transitions, then you must make sure that the status group mapped to the service request type and responsibility of the person creating the relationship:

Note: The application automatically sends an Oracle Workflow notification to the service request owner if the automatic status update fails. You can modify the text of the Oracle Workflow message “Notify: Service Request Update Failed Message”. The item type for this message is Service Request (Internal Name: SERVEREQ).

Note: If you plan to automatically close duplicate service requests that require approvals via electronic signatures (as described in Electronic Approvals and Records) then do not use the predefined Closed status as a triggering status or as an Approval Action status. Create alternate statuses instead.

This makes it possible to distinguish between the two different types of closure and prevents approvers from being forced to approve duplicate requests.

Permitted Modifications to Service Request Relationships

While you are not permitted to add relationship types, you can:

Changing the Wording of a Relationship Type or Removing It from Use

Use this procedure to change the wording users see in the Relationship Type list of values or to remove a link type from use.

To change the wording for a relationship type or remove it from use

  1. From the Navigator, navigate to Setup, then Definitions, Relationships and Valid Objects.

    The Relationships and Valid Objects page appears.

    the picture is described in the document text

  2. To modify the wording of a relationship agents see in the LOV, modify the Name.

  3. To restrict the availability of a relationship use the start and end date fields.

    Note: Because the relationships are reciprocal and come in pairs, restricting the availability of one relationship type automatically restricts the availability of its reciprocal.

  4. Click Apply to save your work.

  5. To permit linking of service requests to objects other than service requests using the “Reference for” and “Refers to” link pair, click Update Valid Objects (the pencil icon) in the Reference for row and follow the procedure outlined in Adding Reference Links to Objects Other Than Service Requests.

Setting Up Reference Links to Objects Other Than Service Requests

Use this procedure to make it possible for users to link service requests to objects using the “Refers to” relationship link. The system automatically creates the reciprocal “Reference for” relationship. By default, this relationship type is already set up for service requests.

Prerequisites:

You must set up the objects you want to link to service requests using the Task Setup: Object Types window which is available by navigating to Task and Escalation Manager, Setup, Objects Metadata under the CRM Administrator Responsibility.

See "Setting Up Metadata Objects" in Oracle Common Application Calendar Implementation Guide for details.

To set up reference links to objects other than service requests

  1. From the Navigator, navigate to Setup, then Definitions, and select Relationships and Valid Objects.

    The Relationships and Valid Objects page appears.

    the picture is described in the document text

  2. Click Update Valid Objects (the pencil icon) in the “Reference for” row.

    The Valid Objects page appears.

    the picture is described in the document text

  3. Click Add Another Row.

  4. From Relationship Type list, select Refers to.

  5. Click Search for Related Object Type (the searchlight icon in the Related Object Type column.)

    The Search and Select: Related Object Type page appears.

  6. Click Go to display all objects you have defined.

  7. Select the option next to the name of the object.

  8. Click Select.

    The object you selected appears in the Valid Objects: Reference for and Refers to Relationships page.

  9. Click Apply .

Turning Off Automatic Service Request Status Updates Rules

Use this procedure to turn off any of the predefined automatic service request status update rules. You cannot add rules or modify them.

To turn off automatic service request status update rules

  1. To turn off automatic service request status update rules: Under the Service responsibility, navigate to Setup, then Rules, and select Status Update Rules.

    The View Automatic Status Update Rules page appears.

    the picture is described in the document text

  2. Click View Event Details (the glasses icon) to the right of the rule type you wish to disable.

    The View Event Details page appears. The page displays different details depending on the rule type you have chosen.

    the picture is described in the document text

  3. Enter an end date for any rule you want to disable.

  4. Click Apply.

    Note: You can modify the resolution code and the service request status for the Duplicate Of relationship. For the Caused By relationship you can change the service request status. See"Setting Up Service Request Statuses" for more information.