This chapter covers the following topics:
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:
Caused by
Root cause of
Duplicate of
Original for
Reference for
Refers to
Only the last two relationship types can be used to link service requests to other objects you set up:
Reference for
Refers to
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:
Caused by / Root cause of
Duplicate of / Original for
Reference for / Refers to
The following two relationship pairs also propagate status changes between the linked service requests:
Caused by/Root cause of
Duplicate of/Original for
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:
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:
|
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:
A service request can be a duplicate of only one original.
Service requests that are originals for others cannot be chained.
Service requests that are the cause of or caused by others cause logical errors in the status propagation.
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:
Includes the seeded statuses of "Waiting", "Clear", and "Closed".
Permits all statuses to transition to "Closed". This is required for the application to automatically close duplicate service requests through status propagation.
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.
While you are not permitted to add relationship types, you can:
Change relationship wording or remove a relationship type from use.
Add reference type links to objects other than service requests.
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
From the Navigator, navigate to Setup, then Definitions, Relationships and Valid Objects.
The Relationships and Valid Objects page appears.
To modify the wording of a relationship agents see in the LOV, modify the Name.
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.
Click Apply to save your work.
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.
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
From the Navigator, navigate to Setup, then Definitions, and select Relationships and Valid Objects.
The Relationships and Valid Objects page appears.
Click Update Valid Objects (the pencil icon) in the "Reference for" row.
The Valid Objects page appears.
Click Add Another Row.
From Relationship Type list, select Refers to.
Click Search for Related Object Type (the searchlight icon in the Related Object Type column.)
The Search and Select: Related Object Type page appears.
Click Go to display all objects you have defined.
Select the option next to the name of the object.
Click Select.
The object you selected appears in the Valid Objects: Reference for and Refers to Relationships page.
Click Apply .
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
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.
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.
Enter an end date for any rule you want to disable.
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.