Navigating the Incident Object
The incident object in Cherwell covers both Incidents and Service Requests in one form.
The incident object is what we most commonly refer to as a "ticket" when talking with our end-users.
As mentioned in Navigating Cherwell, the incident form is comprised of the Information bar and the Content tabs.
The primary tab for Incident is the 'Overview' tab. This tab is made up of three sections:
- C2a: Form Fields
- C2b: Additional Questions
- C2c: Actions
-
The Information Bar
The information Bar Contains information about the:
- Priority
- Incident ID
- Summary
- Status
- Service Level Agreement
- Pending State
- Customer
- Technician and Team Assignment
- Timestamps
Priority
The Incident Priority lets us know when an incident has a higher perceived impact or urgency.
Incident ID
The Incident ID is the record number for the incident. This is used as a reference for the customer and technicians.
Summary
The Summary is a short (150 characters or less) summary of the incident. This is used to quickly filter tickets.
Status
The status of the incident is the current phase that the incident is in.
The status indicator also features a link to change the current status of the active record. This link is the primary method of manipulating the ticket lifecycle.
Service Level Agreements
Every service has an agreed upon service level (SLA) that we target for how we will provide that service. This SLA is displayed for us to track how long we have to respond, and how quickly we are expected to resolve the ticket, based upon the SLA.
SLAs are typically service specific and are supposed to be reasonable. The goal is to stay within the target of the SLA and not breach it. If an SLA is breached it means we need to either renegotiate the terms of it, or assess the root cause of the specific breach.
Pending State
The pending status is displayed when a ticket is in the pending state. This contains the reason for the pended state and a date that we should review the ticket again if we have not received whatever it is we are waiting for.
Customer
The customer is the person for whom the ticket is for. We sometimes use the term 'requestor' meaning, the person requesting this service. The customer should be whom the ticket is for, and not necessarily the person who submitted the ticket.
EX: A new employee starting would have access requested by a supervisor. We should put the ticket in the employees name not the supervisors.
Technician and Team Assigned
This is information about who currently "owns" the ticket. Owning a ticket refers to the technician or team that are currently assigned to complete the work. A ticket may be assigned to a team and technician, or just a team. If a ticket is assigned to a team, it means that anyone from the team could 'take ownership' of it to complete the request.
Timestamps
The timestamps show when the ticket was created and by whom.
-
Form Fields
The ticket field area includes the following information. All information entered here should be considered end-user view able unless otherwise noted!
Call Source
This is the channel where the ticket was created. eg: phone, portal, in person etc.
Customer
The primary customer of the ticket. This is for whom the ticket is for. Not necessarily the person who entered it. This is a lookup to the customer table, which is an import from Workday. We do not manually create new customer records.
Customers without a WPI account (no ID or Email Address) are called "Default Customer."
Alternate Email
If a user provides a non-WPI email, this can be added to this field. If the user is a Default Customer, the email will populate in the TO field when emailing the user, otherwise it will populate in the CC field of the email.
Contact Name
Utilize the contact name for Default Customers or for a reminder on the name used in the email signature of the customer.
Summary
A very short (150 characters or less) summary of the ticket. It may be tempting to create lexicon and shorthand here like [House Call] or [Call User] then the description, but this field should only be used for the summary.
Public Field!Description
A description of the issue without posturing, or offering solutions. This description should be thorough, and include a detailed summary of the situation, but should not include opinions, or proposed solutions. Dialogue and notes can go into the Journal tab.
Public Field!Service Classification
This is the Service catalog (Portfolio, service, component) of the requested item or reported issue. This is a search box that helps us to find the service we need.
Priority
Priority is assessed based upon the service definition but is a matrix of impact and urgency.
Primary Configuration Item
This is the system, computer, or other asset that this request or incident is for. They are imported from a discovery tool called Cherwell Asset Management (CAM).
Assigned Team
The team that will own communication for this ticket. Any member of this team may email or use Email and Pend, even if that individual does not own the ticket. (Assigned team may differ from the team that is doing the work.)
Assigned To
This is the individual that will be owning communication, and accountability for follow-up on this ticket. This may not be the person doing the work.
-
Additional Questions
Additional Questions are a dynamic form based upon the current classification of the ticket.
These forms are typically a mix of troubleshooting steps, documentation, and additional information needed to fulfill a ticket.
-
Actions
The incidents actions list is a dynamic list of actions that allow you to "do things" on the ticket.
Assign to Me
This will take the current ticket and assign it to your primary team, and yourself.
Escalate to Level (2 or 3)
This link will escalate the ticket to the next tier. This is dynamic based upon the selected service. eg: a ticket can flow from 1) Service Desk 2) Service Desk Staff 3) Systems Operations using this workflow.
Link to Existing or Changing to a Major Incident
If there are many incoming tickets about the same large scale issue (eg. many reports of a phishing attempt, or a network outage) we can combine those incidents into a Major Incident. This link will provide new workflow actions for managing them together.
Create a Problem
Similar to a major incident, a problem is a tool for doing root cause analysis when there is a major issue that we do not know the cause of yet. Problems can capture solutions and workarounds for an issue, and can help carryout the RCA process.
Create a Change Request
Any time we want to change a configuration item (any changes made to a Production System), we track that in a Change Request. This link will use some information from the ticket and let you create a change.
View Impacted CIs
Using the CI information entered in the form fields, we can track downstream impact from issues with the reported CI.
Select Available SCT
Service Catalog Templates (SCT) are sequences of tasks that can be generated from the current selected service. The benefit of these templates is that we can generate tasks for other teams, with dependencies and timings, in a repeatable manner. Using this button will generate the SCTs for the current ticket's classification.
Track Time
Sometimes when working on a ticket, there isn't a specific task, but we want to track out time worked. This link lets us add a report entry for time spent on a ticket.
Email & Set to Pending
Pressing this button displays the email prompt, where you can compose your message to the Customer / Subscribers. When the email is sent, the ticket is automatically set to Pending status (with the Review By Deadline 3 business days away and the Pending Reason set to Awaiting User Response).
If you prefer not to pend the ticket automatically, you may use the customer’s email address button in the Information Bar.