JSDV2 Email Channel

The Service Desk has the ability to receive email input communication from itsd@sacsewer.com. These emails are now routed to our Service Desk under the Request Type "Report a Problem" even though these really are not considered Break Fixes. Our email notifications do not have the ability to distinguish Incidents from Service Requests. In order for our Service Desk agents to initially triage the email notification we had to change the request type. from a Service Request to an Incident. The email notifications will flow into the Email Requests Queue for Triage as depicted below:

Defaults are set as follows:

Report a Problem (Incident) SLAs apply.
Request Type = Report a Problem
Status = Open
Component/s = Applications
Channel = Email
Assigned Group = Reg San Tech (This does not mean that this team owns working these email requests both Tier 1 IT Service Desk agents at both sites are responsible. This only defaults out of necessity.)
Assignee = Unassigned (do not change this)

EXAMPLE:

It will be up to the Tier 1 Technician to determine the correct categorization of the ticket depending on the Customer Description. Most likely, this will require changing the ticket from an Incident to a Service Request.

The ticket now needs to be categorized correctly:

Change from Incident to Service Request:

Click "Next"

Change the initial Incident Status of "Open" to Service Request Status of "Intake" this will force the Service Request workflow to start. All Service Requests require Approvals before IT engages in fulfillment.

Click "Next"

The following Service Request fields need to be completed:

Requesting Cost Center (Reporter's Cost Center - you can look this up in the Employee Search SDA; most likely this will be 30285 - Reg. San Fiscal/Adm)
Requested Service: Customer Account Services (you have to choose this before the Service Type dropdown is populated - these are not in order)
Service Type & Customer Request Type for most will be Deactivate User Account (because these requests are being submitted with multiple services types you will have to decide which is most appropriate)

Click "Next"

Confirm on the next screen the fields are updated correctly, if so, Click "Move" the ticket will now look like this:

Please note: Type is now Service Request, Status/Customer Status is now "Waiting for Approval" with No SLAs. Service Type/Request Type is now "Deactivate User Account". Channel remains as Email.

THE FOLLOWING STEPS MAY NOT BE REQUIRED FOR ALL TYPES OF SERVICE REQUESTS. FOR SERVICE REQUESTS THAT HAVE ASSOCIATED PRODUCT OWNERS THOSE APPROVALS WILL HAPPEN AUTOMTICALLY.

The next step is to determine the personnel's account to be Deactivated Supervisor to Re-send for approval (this information can be obtained from the Employee Search SDA by putting in the person's first, last name and locating their Timesheet Supervisor's name):

Click the Re-send for approval button, the following dialog box appears:

Click "Re-send for Approval" button.

Click "Send for Approval" button

Once approval is achieved, then update the Assigned Group using the Edit feature:

Change the Assigned Group from Reg San Tech to ITOPS:

This will cause the Service Request to flow into ITOPS queue with a Status of "Waiting for Support". This is the last step.

Do not set Assignee, as the ITOPS team will assign within their group.

Note: We realize there a quite a few more steps to this process now because we are capturing more data fields for Service Requests. The way to simply this process would require a change to the business process that supports this process that automatically emails these requests to IT. Additionally, our system was not designed to handle multiple service types within one (1) request which is proving problematic when multiple supervisors may be required to approve deactivations. Another solution would be for the business to stop emailing the Personnel Announcement Tickets but rather enter those one at a time through the IT Service Desk portal. We did not want to disrupt the business at this time.