JSCookMenu

Resolving Tickets Print
Thank you for visiting the Remedy Request for Service (RFS) page, which outlines how to resolve RFS tickets. The Request for Service application is the problem-tracking system used by the majority of help desks at UNC. By using RFS, SOP staff and faculty can receive prompt service to issues associated with networking and other computer problems that may otherwise prevent them from completing their daily work.

To download RFS applications, go here. Note: The following information about the RFS application originates from UNC's Remedy web site and has been adapted with permission. For more information about Remedy, please go to the Remedy site. If you would like to review some of the most important Remedy functions, please click on one of the links below:

Opening/Creating a Ticket
RFS File Menu and Toolbar Functions
Entering RFS Ticket Data
Categorizing a Request
Assigning a Request to a Group Securing a RFS Ticket
Choosing a Severity Level Creating a Ticket Via Email
Monitoring for New Tickets
Acknowledging/Responding to a Ticket
Updating or Modifying an Existing Ticket
Viewing the Status History of a Ticket
The Ticket Audit Trail
Resolving a RFS Ticket

 

RFS Overview

The RFS application is the most widely used Remedy application at UNC. This document will serve to discuss the life cycle of a "Request for Service." Throughout this discussion of RFS, the words "ticket" and "request" will be used interchangeably as well as "UNC-Request for Service" and "RFS."

The Request for Service application can be displayed in two different modes: SAVE mode and SEARCH mode. SAVE mode is indicated in RFS by a green background color. The SAVE button located in the upper right corner of the form is used to create or modify requests. SEARCH mode is indicated in RFS by a blue background color and the SEARCH button located in the upper right corner of the form is used to find an existing request.

Figure 1: UNC-Request for Service: Modify Window
RFS Figure 1a

 

Opening/Creating a Ticket

One of the most common Remedy functions used at UNC is submitting a Request for Service when a customer needs technical support. To open the RFS, first log on to the Remedy client using your ONYEN. Next, open the REQUEST FOR SERVICE form. There are several ways to open a form:

1. From the FILE MENU, select FILE, OPEN, then select UNC-REQUEST FOR SERVICE from the list of forms and click on the NEW button at the bottom window.

2. When UNC-REQUEST FOR SERVICE is open, enter customer information using either of the following methods:
a) Enter the customer's PID into the
field. With the cursor in the PID field, press ENTER to automatically populate the rest of the customer's information, OR
b) Make the appropriate selection from the STUDENT/FACULTY/STAFF field, enter their last name into the LAST NAME field and press ENTER. This will give you a list of names to choose from. Make the appropriate selection and click OK.

OPTIONAL: Enter the problem as the customer describes it into the CLIENT'S PROBLEM DESCRIPTION field.

3. Make a selection from the SHORT DESCRIPTION field that best fits the problem.

4. If you're working on the problem yourself, click on the ACKNOWLEDGE TICKET button. If not, decide which group should handle the problem and make a selection from the GROUP ASSIGNED menu.

5. Make a selection from the SEVERITY menu (see Choosing a Severity Level below)

OPTIONAL: If you know the particular person that will handle the problem, select them from the PERSON ASSIGNED menu. If you plan to work on the problem yourself, this function isn't required, because by hitting ACKNOWLEDGE TICKET as described above, you have already populated this field with your user ID.

6. Write a detailed description of the problem in the Worklog and include any information that will help solve the problem.

7. Doublecheck to ensure all fields in bold are filled in.

8. Click SAVE on the upper right to save the ticket.


If most of your work in Remedy involves creating tickets, you can set up your default form, RFS, in SAVE mode when you log on to Remedy.

1. Open RFS as discussed above in SAVE mode.

2. Select from the FILE menu, TOOLS, OPTIONS, GENERAL tab.

3. Check the SAVE WINDOW WORKSPACE option. Now select FILE, EXIT.

4. Login to Remedy again and select TOOLS, OPTIONS, GENERAL tab and uncheck the SAVE WINDOW WORKSPACE option.

Now, after you login to Remedy, the RFS will open automatically in SAVE mode.

 

RFS File Menu and Toolbar Functions

Figure 2: Remedy Icons
Fig. 2b RFS

Remedy displays the icons shown above only when the RFS application window is open. Corresponding FILE menu items are listed under UNC duplicate functionality within the icons.

1. Change Password: Remedy authenticates users against their Onyen password, so your Remedy password is your Onyen password. Please refer to the Onyen Page to change your Remedy password.

2. CCI Student Purchases: This macro displays the IT Profile window for CCI machines associated with a student PID. The IT Profile provides Hardware, Serial Number, Insurance and CCI configuration information for the PC.

3. List My Open Tickets: This is a macro that will search for and display any open tickets that are assigned to you.

4. List Group Open Tickets: This is a macro that will search for and display any open tickets that are assigned to your group, whether Person Assigned is specified or not.

5. Preview Ticket Summary

6. Close All Windows: This is a macro that will close all windows (forms) that are currently open.

7. List Multi-Group Tickets: This macro will search all of your groups for open tickets and display them, whether Person Assigned is specified or not.

8. Change My Initial Notification: Allows you quick access to the User form where you can perform the following functions:

  • Change your initial notification between Notifier and Email
  • Change your contact method between an email address and a pager address
  • Change your notification types: long notifications (ideal for an email) and short notifications (ideal for a page)


Entering RFS Ticket Data

Remedy provides several ways to access RFS, and tickets can be created via:

Entering Customer Information

Enter the customer's information by using one of the following three methods. All fields labeled in BOLD TYPE are required fields. Remedy will display an error message if required fields have not been completed, detailing which values remain to be completed.

1. Type the customer's PID number in the PID field and press ENTER. The cursor must be in the PID field when you press ENTER. This will populate the entire customer information section.

2. Type the customer's Onyen in the ONYEN field and press ENTER. The cursor must be in the Onyen field when you press ENTER. This will populate the entire customer information section.

3. Select a value from the STUDENT/FACULTY/STAFF menu, enter the customer's last name into the LAST NAME field and press ENTER. The cursor must be in the LAST NAME field when you press ENTER. When the SELECTION BOX appears, choose the appropriate customer and double-click. This will populate the customer information section for you. In addition to the LAST NAME field, you can enter a whole or partial value into the FIRST NAME field to narrow down the query. When the selection box appears, choose the appropriate customer and double-click. This will populate the customer information section for you.

4. Select a value from STUDENT/FACULTY/STAFF menu, enter the customer's whole or partial email address into the EMAIL field and press ENTER. Clicking SAVE now will generate an email.

Note: Onyen account information is refreshed daily before 6 AM, therefore any Onyen account created after that time will not be a valid selection until the following morning. Remedy Services does not maintain ownership of customer data. Customers may have multiple entries if they are classified as both a student and faculty or staff. Customer information may be incomplete or contain inaccurate information.

Correcting Missing or Inaccurate Customer Information

Remedy Services receives data from the main on-line campus directory. If any of this information is incorrect please refer to documentation provided at the Campus Directory Login page for instructions on how to modify the directory information. Change forms are also available inside the printed version of the current Campus Directory. Also consult the HelpSite FAQ How do I change the customer information such as telephone number, email address, department or building information within the Request for Service? .

Finding Out Who Supports the Customer

If you are unsure which Remedy group supports the customer submitting the request, select the ? beside the Department name in the customer information section of the Request for Service. A window will display the three support tiers defined within Remedy for the department the customer belongs to.

Remedy Best practices: Check for Duplicate Requests for a Customer


Categorizing a Request

Most Remedy groups drive categorizations based on the SHORT DESCRIPTION menu in RFS. By selecting a Short Description that best describes the request, other values including: CAMPUS PRIMARY CATEGORY, CAMPUS SECONDARY CATEGORY, TOPIC AFFECTED, and ITEM AFFECTED may be populated. Some groups have larger Short Description menus that auto-populate all values, while others use a more complex classification of requests by allowing users to differentiate request types using the above mentioned fields.

Select a SHORT DESCRIPTION and ensure that the CAMPUS PRIMARY CATEGORY and CAMPUS SECONDARY CATEGORY (in bold type within the Request for Service) have values. Any field labeled in bold type is required before saving or submitting a request.

Enter more detailed information about the request from the customer in the CLIENT’S PROBLEM DESCRIPTION field located below the SHORT DESCRIPTION menu. This information will be saved to the WORKLOG field when the request is saved.

Note: All information saved to the WORKLOG is permanent and cannot be removed from the request.


Assigning the Request to a Group

Each Remedy group defines their own workflow for interacting with other groups and exchanging Remedy tickets. By default, all Remedy groups see the following groups in their Group Assigned menu:

REMEDY ADMIN: All Remedy groups may assign requests for assistance to Remedy Services.

ACCESSIBILITY: By law, accessibility issues must be addressed by all groups on campus.

ITS-CONTROL CENTER: ITS provides off-hour monitoring services for all CRITICAL tickets.

ITS-SECURITY: The Security group needs access to resolve security issues for all groups.

ITRC-MANAGERS: Sherry Graham, director of Response Services is available for all groups.

ITS-HELP: Anyone at UNC may submit an online help request from help.unc.edu.

When choosing a group to assign a request to, you may notice that most groups are listed in UPPERCASE. Other groups are listed in upper and lower case. Groups with names that may not be intuitive have chosen to display a user-friendly alias. For example, SOE-ITS displays an alias "School of Education" to users choosing a group, but then replaces the alias with their Remedy group name SOE-ITS .

Remedy Best practices: Never assign a ticket directly to an individual. Group assignment prevents tickets from being overlooked while an individual is in meetings or on vacation. Only assign a ticket to an individual when creating a ticket if the person is expecting the request to be assigned to them. If you do not see a group that you would like to exchange tickets with, submit a request and assign it to REMEDY ADMIN. You will need to get prior agreement from management in the other group before contacting Remedy Services. Again, each group is allowed to maintain its own business work flow for interacting with other groups. This step ensures a fair exchange of tickets between groups.


Securing an RFS Ticket

Some Remedy groups deal with sensitive or confidential information such as human resources or campus security groups. The RFS allows these groups to restrict access to several fields including the SHORT DESCRIPTION, CLIENT’S PROBLEM DESCRIPTION, CUSTOM DATA, and WORKLOG fields. After a ticket has been secured, it cannot be unsecured by any group except REMEDY ADMIN.

 

Figure 3: UNC-Request for Service, Secure Ticket Functionality
Fig. 3 RFS


To secure a ticket:

1. Select a secure Remedy group in the GROUP ASSIGNED field. Currently, only ITS-SECURITY, ITS-FS-HR, and all HRIS groups are secure groups.

2. Select the SECURE ticket button labeled in red that will appear above the GROUP ASSIGNED field

3. A prompt will replace the SECURE TICKET button, requiring you to select OK to accept the request being secured or CANCEL to prevent the ticket from being secured.

Secured tickets will display "padlock" icons beside the SHORT DESCRIPTION, CLIENT’S PROBLEM DESCRIPTION, CUSTOM DATA, and WORKLOG fields.

 

Choosing a Severity Level

The Severity level chosen for an RFS ticket defines how urgently a group will respond and resolve your request. Each Remedy group establishes a SERVICE LEVEL AGREEMENT (SLA) for each of the three SEVERITY LEVELS in the Request for Service. Notifications such as email or pager messages are sent from Remedy at time intervals specified by the GROUP ASSIGNED after a ticket is created based on the Severity and the GROUP ASSIGNED the request. Group SLAs are defined for both RESPONSE TIME, the amount of time it takes a group to Acknowledge or take ownership of a request, and RESOLUTION TIME, the amount of time it takes to complete a request. The three SEVERITY LEVELS are: CRITICAL, IMPORTANT, and GENERAL. Here are some guidelines for defining Severity:

1. CRITICAL: A problem that affects multiple users such that University business is disrupted or a situation that affects an individual's heath/safety or a problem that affects the ability to complete critical work.

2. IMPORTANT: A problem that affects an individual but does not prevent work in other areas.

3. GENERAL: Problems that are neither critical nor important.

 

Checking a Group's Service Level Agreement

Before you submit your request, check the Service Level Agreement that the group responding to your request has agreed to provide. Select the ? just right of the GROUP ASSIGNED menu. A window will display the SLA provided for responding to your request. See the example below for the ITS-WIN-INFRASTRUCTURE Remedy group (Figure 4: UNC-Request for Service, SLA Window):
Fig. 4 RFS

 

If you are creating a ticket for a customer, you can provide them with the group's Service Level Agreement.

Submitting or Saving the Request

After you have completed all fields labeled with bold type, you can submit the request by selecting the SAVE button in the top right corner of the RFS window. If you receive an error message, the message should direct you on how to resolve the error.

 

Creating a Ticket via Email

There is a function called "Email-In" in the UNC-CH Remedy application that allows you to create tickets from an email message. This is useful if you are a Remedy user but are not at a machine that has Remedy installed or if you receive a lot of email requests that you would like to enter as tickets. Email-In lets you forward an email message to a specified email address which sets up default values and creates the Remedy ticket for your group.

In order to set up Email-In, the Group Data Administrator for your Remedy group needs to:

1. Set up an email alias which points to remedy@email.unc.edu. You can do this by emailing the request to alias@unc.edu. This alias should be meaningful to your group. For example, if Remedy Services wanted to set up an email alias, it might be "remedy_question@unc.edu."

2. Decide what values you want automatically populated in the tickets created via email. Values in the CUSTOMER INFORMATION section of the UNC-Request for Service will be generic, so you will need to correct them once the ticket is created. These values will be used in every ticket created from your alias. The following is a list of fields in the template that the Group Data Administrator will need to provide values for:

  • Email Alias Address
  • Organization Group
  • Status: Student/Faculty/Staff
  • PID
  • Last Name
  • First Name
  • M.I.
  • Point of Contact
  • Phone
  • Short Description
  • Campus Primary Category
  • Campus Secondary Category
  • Group Assigned
  • Severity Level: Critical, Important, General

3. Assign a ticket to REMEDY ADMIN requesting that an Email-In template be set up for your group. Include your Remedy group name and the values you've chosen for required fields in the ticket.

 

How to Create Email Tickets After the Email-In Template is Set Up

1. Open a new mail window or the forwarding window if you want to forward an existing email in your email client.

2. Enter your group's email alias in the To: field of the email message.

3. Enter a description of the request in the Subject: field and enter any details in the body of the email.

4. Most mail clients send in HTML format. Choose plain text and disable any v-cards or signature files to reduce formatting text that can clutter the worklog of the ticket.

5. Do not send attachments with the email message.

6. Send the message.

Remedy runs a query every 5 minutes for new mail messages. When the message is received, Remedy creates a new Request for Service ticket with the Subject: line pushed into the CLIENT’S PROBLEM DESCRIPTION field and the body of the email pushed to the WORKLOG. The ticket is then assigned to your group.


Monitoring for New Tickets

Many groups across the UNC-Chapel Hill campus have defined aggressive Service Level Agreements for requests submitted to their groups, and Remedy provides several methods for ticket monitoring.

1. Remedy Notifier: See the HelpSite document Using Remedy Notifier .

2. Remedy Alert: See the HelpSite document Using Remedy Alert .

3. Group Notifications: Email or Pager

When a Request for Service is submitted, Remedy sends notifications to the group that is assigned to the newly created request in the form of emails or pages, depending on group preferences. Emails will contain the Request Number, Severity, Customer Information, Client's Problem Description, Worklog, and the Group Assigned value as seen in Figure 5 below:
Fig. 5 RFS

 

Remedy will also send individual notifications via email when a ticket is assigned to an individual. Information contained within the email is consistent with group assignment with the exception of the Subject, which is modified to read: "Ticket 457039 assigned to you."

A complete review of all emails sent via Remedy is available on the Remedy Services website.

4. Auto-Refresh of RFS Search Window:

If you are required to monitor your Remedy group's queue for new requests, Remedy allows you to perform a search and let Remedy poll for the search at an interval of your choosing. From the UNC-Request for Service:

1. Run the LIST MY OPEN TICKETS macro from the FILE menu, UNC, LIST GROUP OPEN TICKETS or by using the "two-headed" icon below the FILE menu.

2. When you get the results, go to VIEW, AUTO-REFRESH.

3. Select the ON radio button.

4. Enter a time interval in a measurement of minutes.

5. Click OK.

 

Acknowledging/Responding to a Ticket

Responding to RFS tickets is fairly simple. Follow these eight steps to complete the response cycle:

1. Go to FILE, OPEN.

2. Select UNC-Request for Service from the list of forms and click on the SEARCH button at the bottom of the window.

3. When the UNC-Request for Service window opens, enter the ticket number that displayed in the notification into the REQUEST NUMBER field.

4. Click on SEARCH in the upper right to pull up the ticket. SHORTCUT: You may also pull up the ticket simply by clicking on the LIST GROUP OPEN TICKETS field and then finding your ticket in that list.

5. When the ticket displays, click on ACKNOWLEDGE TICKET (document your work in the Worklog).

6. After the problem has been solved, click SOLVED from the STATUS menu. If the ticket needs to be sent to another group or individual, make the appropriate selections from the GROUP ASSIGNED and PERSON ASSIGNED menus.

7. Click SAVE in the upper right to save the ticket.


The RFS application also allows each Remedy group to define Service Level Agreements (SLA) for requests submitted to their groups, allowing them to monitor SLA compliance for both Response Time and Resolution Time. These SLAs are based on the STATUS, SEVERITY, and GROUP ASSIGNED values of each request. The default STATUS for newly created tickets is set to ASSIGNED.

  • Response Time is defined as elapsed time between ticket submission and a group taking ownership for the request. Ownership is taken when a group acknowledges the request. In terms of ticket status, Response Time is the difference between Assigned status and Work In Progress.
  • Resolution Time is defined as the elapsed time between ticket submission and ticket resolution. In terms of ticket status, Resolution Time is the difference between Assigned status and Resolved status, minus all Pending status values.


When your group receives a Request for Service, select the ACKNOWLEDGE TICKET button just left of the STATUS field. Doing this allows three things to happen:

1. The SLA measurement for Response Time stops.

2. The Status field moves from ASSIGNED to WORK IN PROGRESS.

3. The Request for Service is assigned.

Figure 6: Response Time vs. Resolution Time Example
Fig. 6 RFS

 

Updating or Modifying an Existing Ticket

If you do not solve a ticket on initial creation, then there are likely to be occasions when you need to pull up the ticket and update it. An update is defined as any change you make to a ticket after the first save by changing the SHORT DESCRIPTION, changing GROUP ASSIGNED or adding information to the WORKLOG as examples.

Remedy Best practices: Any time you make a change to a ticket, you are encouraged to make notes in the Worklog stating what you have done.

The Modify Window

The MODIFY window, which displays tickets you have retrieved to be updated, contains two sections. The top section, called the RESULTS window, displays the list of tickets that your search returned. The bottom section, called the DETAILS window, displays the details of the ticket selected in the list. When you select a record in the RESULTS list, the display in the DETAILS window reflects the new request.

Updating a Ticket

Tickets that you want to update can be classified three different ways:

1. Those that are assigned to your group but not to you personally.

2. Those that are assigned to you.

3. Those that are not assigned to you or your group.

If you want to update a ticket that is assigned to your group but not to you personally do the following:

1. Open the RFS form by choosing FILE, OPEN. Select UNC-REQUEST FOR SERVICE from the OPEN window and click on NEW.

2. Click on the LIST GROUP OPEN TICKETS button on the toolbar.

3. Select the ticket you want to update from the list displayed in the top section.

4. When that ticket displays in the bottom section of the window, make the necessary changes/updates.

5. Click on the SAVE button.

If you want to update a ticket that is assigned to you, do the following:

1. Open the RFS form by choosing FILE, OPEN. Select UNC- REQUEST FOR SERVICE from the OPEN window and click on NEW.

2. Click on the LIST GROUP OPEN TICKETS button on the toolbar.

3. Select the ticket you want to update from the list displayed in the top section.

4. When that ticket displays in the bottom section of the window, make the necessary changes/updates.

5. Click on the SAVE button.

If you want to update a ticket that is not assigned to you or your group:

1. Open the UNC-Request for Service form by choosing FILE, OPEN. Select UNC- REQUEST FOR SERVICE from the OPEN window and click on SEARCH.

2. Enter the number of the ticket you are searching for in the REQUEST NUMBER field. If you do not know the ticket number, see the section titled FINDING AN EXISTING TICKET to learn about other ways to search for a ticket.

3. Click on the SEARCH button.

4. Select the ticket you want to update from the list displayed in the top section.

5. When that ticket displays in the bottom section of the window, make the necessary changes/updates.

6. Click on the SAVE button.

7. The Group will be notified that someone outside the group has updated the request.


Worklog Entries

Figure 7: UNC-Request for Service, Worklog Diary Field

Fig. 7 RFS

 

The WORKLOG field within RFS is a specialized field called a diary field that records a timestamp and the Onyen of the WORKLOG entry author. Here's an example of what one might look like: "11/11/2003 6:00:52 PM howardt." This note would be displayed above any entry to the WORKLOG. The WORKLOG has two sections, the DIARY HISTORY and DIARY EDITOR. In the RFS, the DIARY HISTORY section is located on the left side of the application and is shaded green, just as the application background. Entries to the Worklog are stored here by default in chronological order. To view the most recent entries first:

1. Select the DIARY icon just right of the WORKLOG field.

2. In the FILE menu, select VIEW and check MOST RECENT FIRST.

3. The most recent WORKLOG entries will be listed at the top of the WORKLOG.

The DIARY EDITOR is located on the right side within RFS and is used to add entries to the WORKLOG. After you enter your text by typing or by pasting text from the clipboard, select the SAVE button in the upper right corner of the application. If you use the DIARY icon to enter text, be sure to select OK after entering your update. If you select CANCEL or X out of the window, your entry will not remain in the DIARY EDITOR to be SAVED .

Updating the Worklog of a Ticket via Email

There may be times when you want to update the Worklog of a ticket without having to log on to the Remedy User Tool. This can be done via email. Using your normal email client, create a new email message and:

1. In the TO: field of the email, enter "updateticket@unc.edu."

2. In the SUBJECT: field of the email, enter the word "Ticket," followed by the number of the Remedy ticket you want to update.

Example: "Subject:Ticket 12345"

You can put additional text in the SUBJECT: field as long as it contains the word "Ticket" followed by a space and the number of the Remedy ticket you want to update.

3. Type the WORKLOG update into the body of the email message.

4. Send the message.

5. The message is sent directly to the Worklog of the specified ticket.

The next time you pull up that ticket, the WORKLOG entry via email will appear in the following format:

Wednesday, February 4 1:20:09 PM web
From: John Doe
To: updateticket@unc.edu
Subject: Ticket 91247
This is the text I am adding to Worklog via email.
 

Sending Email from a Request for Service Ticket

Communication is a key component to resolving requests from customers. Documentation also plays a vital role in support. RFS has combined both communication and documentation in the EMAIL CLIENT tab located just right of the main TICKET SUMMARY tab. Support personnel have the ability to communicate with the customer or with other support groups to obtain additional information needed to resolve the request or to relay updates to the customer on the request's progress. To send email from the EMAIL tab:

1. Select the EMAIL CLIENT tab within the RFS ticket you wish to send a message.

2. By default, the Customer's email address is set in the EMAIL ADDRESS (TO:) field from the customer information located on the TICKET SUMMARY tab and the user logged in the application will have their email address listed in the REPLY TO: field. If you want the user to reply to your group, select USE GROUP ADDRESS to replace your address with a group listserv address.

The EMAIL tab provides a campus directory email lookup feature for the EMAIL ADDRESS, REPLY TO, and CC: fields. Enter the first few characters of an address to display a pick list of matching email addresses from the campus directory. Highlight the appropriate address and select OK to populate one of the address fields.

3. Use a comma and space to separate additional email addresses.

4. Enter your message into the EMAIL TEXT field. Check the spelling of your message by selecting the SPELL CHECKING button.

5. To add context to your email message, you can select YES from the EMAIL WORKLOG? field which will append the entire WORKLOG to your message.

6. To send your message immediately, select the SAVE TICKET and SEND NOW button. If you would like to make additional changes to the ticket before sending, select the SEND ON SAVE button.

The email will be sent to all recipients as well as saved to the worklog of the ticket.

 

Replying to an Email from a Request for Service Ticket

Remedy Best Practices: If you need to reply to an email from an RFS ticket, forward the email to updateticket@unc.edu.

If you are not a member of the Remedy group assigned to the ticket, Remedy will email the Person Assigned to let them know that someone outside their group has updated the request. Emails are sent if changes are made to:

  • Worklog
  • Severity
  • Status

If you are a member of the same Remedy group assigned the request, forward the email to updateticket@unc.edu and CC the Person Assigned. This will capture your reply into the Worklog as well as inform the Person Assigned, which replicates the built-in functionality for tickets modified by non-group members.

 

Attachments and the Request for Service

RFS allows users to add attachments to tickets at any point during the life of a ticket. Currently, Remedy Services limits the number of attachments to 5 with a maximum size of 350kb per attachment.

Figure 8: UNC-Request for Service, Attachments Field
Fig. 8 RFS


To add an attachment from a Request for Service:

1. Select the ATTACHMENTS button above the WORKLOG DIARY HISTORY.

2. This action hides the WORKLOG DIARY HISTORY, revealing the ATTACHMENTS field.

3. Right-click inside the ATTACHMENTS field and select ADD .

4. The WINDOWS ADD ATTACHMENT window will appear. Select the file you want to add and select the OPEN button.

5. If the file has been properly attached, the file name will appear in FILE NAME column within the ATTACHMENT field. Select the Save button to save the document to the Remedy database.

6. If you refresh the ticket by selecting F5, the ATTACHMENTS field will be hidden and the ATTACHMENTS button text will change red in color.

To view an attachment from a RFS:

1. Select the red text ATTACHMENTS button to reveal the ATTACHMENTS field.

2. Double-click the file you wish to view.

If you wish to modify a file saved to an RFS ticket, view the attachment as described above and save the file locally. Right-click on the file name in the ATTACHMENTS field and select DELETE. After you have made changes to the locally saved copy, repeat the steps to add an attachment.


Viewing the Status History of a Ticket

Figure 9: UNC-Request for Service, Status History Window
Fig. 9 RFS

 

After you search for and find a ticket, you have the option of seeing the status history. This will provide information on when a ticket changed status (i.e. from Assigned to Work In Progress) and who was assigned the ticket when the status changed. To use this function, select a ticket from the top section of the search results and select VIEW, STATUS HISTORY from the FILE menu. The status of a ticket is not dependent on the person assigned to the request as it is passed from person to person, so this function will not necessarily show every person who has touched the ticket. The last entry with a MODIFIED BY of AR_ESCALATOR indicates when the Remedy application modified the request. A more detailed history of a request can be obtained from the Audit Trail located on the TICKET HISTORY tab within RFS.


The Ticket Audit Trail

Figure 10: UNC-Request for Service, Ticket Audit Trail
Fig. 10 RFS


The life cycle of some requests can become quite complex. Changes in ownership, classification, and status can quickly transform a simple request into a twisted labyrinth of worklog entries. The Ticket Audit trail is very useful in dissecting more complex requests into digestible, organized units. This table displays up to 40 modifications made to any of the following fields:

  • Modified Date
  • Last Modified By
  • Group Assigned
  • Person Assigned
  • Short Description
  • Item Affected
  • Status
  • Severity
  • Ack-Tkt
  • Follow-Email
  • Worklog Entry

Remedy stores a timestamp each time one of the fields above is modified. In both the ACK-TKT and WORKLOG ENTRY fields, Remedy stores values as 0 for "No" and 1 for "Yes." If you are unsure who modified the entry by viewing the Onyen stored in the LAST MODIFIED BY field, use the WHO IS? lookup located above the TICKET AUDIT TRAIL table. Enter the Onyen you want to search and press ENTER. The Full Name, Group and Phone Number of the individual that modified the record will be displayed.


Remedy Blox Functionality

Figure 11: UNC-Request for Service, Blox Functionality

Fig. 11 RFS

 

The spread of computer viruses through security flaws in browsers, mail clients, and servers has presented the University with the challenge of maintaining a stable network environment for all campus services. When a computer is suspected of violating the acceptable use policy or is determined to be a threat to network stability because of virus activity, Networking isolates the machine from the campus network. Remedy Requests for Service may be created to track the process of isolating a machine. If you work in a helpdesk environment and begin creating an RFS ticket by completing the customer information, you may see two additional tabs: the CLIENT’S OPEN TICKETS tab and the BLOX tab as shown above in Figure 11.

The CLIENT’S OPEN TICKETS tab will display a table of all open RFS tickets that have been created for the customer located on the TICKET SUMMARY tab. By reviewing this tab, users can prevent multiple tickets from being created for the same request.

The BLOX tab displays information needed by Networking groups and the Control Center to monitor and resolve tickets for machines that have been isolated from the campus network.

In reviewing Remedy Blox functionality, isolated machines belonging to a customer will:

  • Display the CLIENT’S OPEN TICKETS tab, indicating open tickets for the customer
  • Display the BLOX tab in blue containing location, IP information, and isolation technique
  • Display the TOPIC AFFECTED field as Isolation Technique
  • Display the ITEM AFFECTED field as a read-only field, preventing modifications

The ITEM AFFECTED field is used by the Control Center to push Remedy ticket information to a website used by support staff and customers to easily display information about machines that have been isolated from the campus network. For more information, view the Control Center Blox Monitor page.

Resolving Blox RFS Tickets

Tickets that have the Item Affected field disabled as shown in Figure 11 above can only be resolved by ITS-SECURITY or ITS-CONTROL CENTER . Remedy checks the Topic Affected and Item Affected listed in the request when the status is set to any of the Solved values. If they do not match the Group Assigned values an error message will be displayed, preventing the request from being resolved. Because the ITEM AFFECTED field cannot be modified for blox tickets, the request must be reassigned to ITS-SECURITY or ITS-CONTROL CENTER to be resolved.

 

Linking a Request for Service with a Project Tracking System (PTS) Request

Figure 12: PTS-Bridge form to Link RFS Tickets with PTS Projects
Fig. 12 RFS

 

Many groups across campus use RFS to document and track requests that can be completed in a relatively short amount of time while other requests have a broader scope that could be more effectively accomplished in a project. Remedy Development has created the Project Tracking System (PTS) to accommodate larger requests that have different dependencies for time and effort than most smaller requests. During the lifecycle of a Request for Service, it may be useful to link an RFS ticket to an ongoing PTS project. To link an RFS ticket with a PTS ticket, from the modify window of an existing RFS ticket:

Select UNC, PROJECT TRACKING. The NEW-PTS BRIDGE form will open.

If you want to link an existing PTS to an RFS ticket:

Click on an open project in the display table below the label "Link this ticket with the following project." After you highlight appropriate project, the PROJECT NUMBER will be displayed to the left of the LINK button. Then select the LINK button. The newly linked PTS will be displayed in the lower display table.

If you want to create a PTS to link to an RFS ticket:

The RFS number is automatically displayed in the upper-right corner of the display window. Now enter any remaining "Required Field" information to create a new PTS project. After you complete the required data, select YES to the REQUIRED FIELDS IDENTIFIED radio button. Select the newly activated CREATE PROJECT button and view the PTS project you just created displayed in the lower display table.

 

Resolving a Request for Service Ticket

After all work for an open RFS ticket has been completed and the customer is satisfied with the result, the ticket may be resolved. Document in the WORKLOG that the customer has been contacted and has approved changing the ticket status to Resolved. Select the STATUS field and change the status of the ticket to Solved, using one of the 5 provided methods of solving a request:

  • Successfully Resolved
  • No Acceptable Solution
  • Issue No Longer Relevant
  • Referral Provided
  • Solution Offered

When a ticket's Status is set to Solved, the Resolution Time calculated for each request is stopped. A request's Resolution Time refers to the time each request has to meet established Service Level Agreements between the customer and the group resolving the request. Additionally, a follow-up email is sent to the customer email address listed in the EMAIL field on the TICKET SUMMARY tab within RFS if the FOLLOW-UP EMAIL flag remains set to its default value of "Yes."

The following sample follow-up email details what the customer receives:

Thank you for contacting us about the issue you reported on 3/10/2004.
A summary of your request and its resolution is shown below.
*************** Summary of Request ***************
RESOLVED BY: Dave (daves)
STATUS: Successfully Resolved
FIRST NAME: jonny-b
LAST NAME: good
LOCATION: 7002 Davis Library
EMAIL ADDRESS: jbg@email.unc.edu
PHONE: 962-0000
DEPARTMENT: acad tech & networking service
TICKET NUMBER: 12345
SHORT DESCRIPTION: Printer needs paper
Printer's out of paper AGAIN!
***************** End of Summary *****************
Let us know how we are doing! Please take a minute to fill out the
service questionnaire at the address below:
http://www.fac.unc.edu/HelpDesk/HowWeDoing.asp?ticket=12345

After the follow-up email is sent to the customer, the Request for Service will remain in a Solved status for 7 days. After 7 days of no ticket updates or modifications, Remedy will automatically set the ticket Status to Closed. Once a ticket is closed, the request cannot be reopened or modified. This includes modifications such as adding information to the WORKLOG of an RFS ticket. If you wish to continue work on a ticket that has been set to Solved for 7 days and is now in a Closed status, you can use the COPY-TO-NEW functionality within the Request for Service.

Figure 13: UNC-Request for Service, Copy to New Dialog Window
Fig. 13 RFS


Copy to New: Selecting CONTROL + T or by selecting from the FILE menu: EDIT, COPY TO NEW. This saves all data values within an existing ticket, with the exception of the WORKLOG, into a new ticket. A dialog window will ask the user if they want to save a reference to the existing ticket within the WORKLOG of the ticket that is being created.

Text such as this example will be appended to the Worklog:

------- This Ticket is a continuation of Ticket 459607 -------

Set to Defaults: If you have default values set up within an application, you can set these values in a NEW or SEARCH window.

Note: Choosing this function clears any existing values in any fields (not just fields that have defaults set up) in the window before populating the default values. Therefore, if you use this function, it is best to initiate it prior to populating the rest of the fields in the New and Search windows and to not use it at all in an existing request in the Modify window.