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.

Incident Overview: C1) Information Bar C2a) Form Fields C2b) Additional Questions C2c) Actions

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
Incident Object Form with blank Incident Form Fields, blank Additional Questions Field, and default 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.

    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!
    The Summary is a public field that the Customer sees.

    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!
    The Description is a public field that the Customer sees.

    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. This may not be 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.