7.1 Service Requests Flashcards
What are Service Requests used for?
manage requests for services that involve an asset or location within the enterprise
Where can a Service Request originate from?
- direct requests from users
(e.g., from a phone call, e-mail, or direct contact) - requests from self-service users who create using the Create Service Request application
- automated workflow process.
What to be mindful of, when an asset or location is being selected on a service request?
the Select Value dialog is slightly different from a regular lookup
What can the Select Value dialog on an SR be filtered by?
either the User/Custodian of assets or locations, or by Public
Describe the owner of a service request
responsible for managing the ticket to completion
How can ownership of a service request be assigned?
can be assigned to another person or person group, or the logged-in user can take ownership as well
Who updates the service request?
The assigned owner can update the service request as more details are found.
List ticket (Service Request) statuses
NEW
QUEUED
INPROG
PENDING
RESOLVED
CLOSE
NEW status
Default status when ticket is created or inserted. This status cannot be used once it is moved out of this status.
QUEUED status
Ticket is in the queue and work can begin.
INPROG status
Work is ongoing.
PENDING status
Ticket is pending an action. For example, work cannot continue until a part is received.
RESOLVED status
Ticket has been resolved. All the activities change to COMPLETE.
CLOSE status
A closed record becomes historical, and status cannot be changed. However, some editable fields can still be changed. All activities change to CLOSED.
How is record management simplified?
Relationships between records
How can tickets and work orders can be related more directly?
when a follow-up record is created from the original record using one of the Create actions on the record
Describe originator and follow-up records
follow-up record is created from the original record using one of the Create actions on the record. The first ticket becomes the originator while the second ticket becomes the follow-up record.
In what cases can a follow-up ticket or work order may be able to change the status of its originating ticket? (What enables this?)
hidden field defaulting the service Request to inherit the status from a follow-up ticket or work order
Rules for follow-up ticket/WO being able to change status of originating ticket
An originating ticket cannot change the status of a follow-up work order, nor can a follow-up ticket change the status of the originator if there is more than one follow-up.
What controls ways in which a Service Request may inherit its status from another record?
INHERITSTATUS attribute
Default value(s) for INHERITSTATUS attribute
Service Requests - 1
Incidents and Problems - 0
List ways in which a Service Request may inherit its status from another record
- A single follow-up ticket to the Service Request
- A Global Issue
- A follow-up work order
Describe limitations pertaining to this:
using a single follow-up ticket to the Service Request
(to enable an SR to inherit its status from another record)
if you create a second follow-up ticket from the Service Request, then INHERITSTATUS is set to 0 and the SR will no longer inherit its status from another ticket.
Describe conditions pertaining to this:
A Global Issue
(to enable an SR to inherit its status from another record)
If the Service Request has a relationship to the Global Issue with relationship type RELATEDTOGLOBAL.
Describe conditions and behaviour pertaining to this:
A follow-up work order
(to enable an SR to inherit its status from another record)
The status is only updated when the work order reaches COMP or CLOSE status, and INPRG if System Property mxe.app.workorder.DoNotChangeTicketToINPROG is set to 0.
The SR status is RESOLVED, CLOSED and INPROG respectively.
If there are multiple follow-up work orders the SR status is updated by the first work order to reach the status.
