Note: Applicable only for accounts in which workspaces have been enabled.


TABLE OF CONTENTS

What are ticket types?

Tickets within a service desk can be classified into ticket types depending on the purpose that they are raised for. Various teams in an organization have a certain preferred ticket type. These preferences are largely based on industry standard practices and primarily for business convenience. Workspace admins can choose their preferred ticket type while setting up a workspace. 


Each ticket type has a prefix or key assigned. Once a ticket type is chosen, all tickets raised to that department will start with the prefix associated with that ticket type.


With workspaces, tickets raised by requesters on the support portal will take prefixes depending on the workspace the ticket is created in. (For e.g. if the ticket is created in HR workspace, the ticket will be of the type that the HR team has chosen)


IT teams typically work on two types of tickets: Incidents and Service Requests. When an IT workspace is created: 

  • The ticket type ‘Incident’ is turned on by default. Incidents can be attached to Problems, Changes & Releases. Additionally, incidents can also be used in modules like On-call management, Alert management. The prefix here is INC.

  • IT workspaces also have another type of ticket which is ‘Service Request’. Any service item requested to the IT workspace will take the prefix ‘SR’. 

Business teams such as HR, Facilities, etc, have the flexibility to choose a ticket type that they prefer. These ticket types have the same functionality but add a different prefix to the ticket ID. The options available are:


  • Case (prefix: CASE)

  • Query (prefix: QUERY)

  • Issue (prefix: ISSUE)

  • Request (prefix: REQ)


What are the functionalities supported by different ticket types?


Here is a table that depicts the same.




How to set up ticket types?

  • Admins can choose the ticket type for a workspace during workspace creation

  • Admins can also update it later from Admin>Field Manager>Ticket Fields>Type. Any ticket created after this will be of the new type enabled. Old tickets will continue to be of the old type.
    Note: The ticket type field is available in the local     field manager settings only and not in the global field manager settings. 


What happens when ‘Incident’ is turned OFF for a workspace?

The ticket type ‘Incident’ is a preferred IT prefix. When it’s enabled, reporting an issue by default logs an incident in the system. When incidents are turned off, the implications are as below:


  1. Requesters will still be able to report issues to the workspace from the support portal or email. However, instead of creating an ‘incident’, it will create a ticket of type 'Service Request'

  2. Certain modules, like Priority Matrix, Alert, and On-call Management, will not work in that workspace since these features work only for the ticket type ‘Incident’.

  3. Any old incident will remain created as an incident. If the incident's property is updated, it will auto-convert into a service request as incidents are no longer supported in the workspace.


What happens when ‘Incident’ is turned ON in a workspace?

  1. Tickets logged to a workspace via ‘Report an Issue’ from the support portal will be created as incidents henceforth with the prefix INC

  2. Tickets logged via email will be created as incidents with the prefix INC

  3. Modules that work only for ‘incidents’ like Priority matrix, Alert and On-call management will work in that workspace


What happens when tickets move between workspaces or the ticket type is updated?

Impact of moving tickets from one workspace to another

All tickets have a unique ID irrespective of the prefix (e.g. SR-1). When tickets move between workspaces, the ID remains intact and only the prefix changes to that of the ticket type enabled in the destination workspace. For e.g. when ticket SR-1 moves from the IT workspace to the HR workspace, it will be renamed to CASE-1. When any ticket is moved from a business team workspace (such as HR) to an IT workspace, the ticket will get converted to a Service Request (SR) always. Please note the following additional aspects that should be keep in mind while moving tickets:

  • Only the capabilities supported by the new ticket type will be retained. For example, a service request moved to a business workspace will lose its change associations because business ticket types do not support "Change" associations. Please refer to the table presented in the above part of the article to understand the supported capabilities for each ticket type.  
  • Requested items details will not be deleted irrespective of which type of ticket is moved.
  • Parent-child associations of tickets of these types -  SRs, Cases, Queries, Issues, and Requests will not be de-linked on cross-workspace movement. However, if an incident is moved to a business workspace, the child tickets will be de-linked because the incident will get converted to a business ticket type. (Incidents can only have parent/child relationships with incidents).
  • Custom field values are still unique to each workspace and cannot be preserved when tickets are moved to a different workspace.

. 

Impact of ticket type conversion within the same workspace:

Given that business workspaces support only Cases, you won't be able to change the ticket type in such workspaces. 

In case you plan to change the type of a ticket from ticket properties in an IT workspace, here is what to keep in mind:

  • Changing an Incident to Service Request would lead to de-linking of Child Tickets. This is because incidents can only have incidents as child tickets but now the parent has been converted to a Service Request. On-call, Alerts and any module not supported by SR will be disassociated.
  • Changing a Service Request to Incident would mean that details of any requested item  will be lost, as requested items are not supported in an Incident. 


What happens to existing tickets when workspace ticket type settings are changed midway?

  • In business workspaces, all new tickets will be of the new type and will therefore take the prefix set after the change. In IT workspaces, if Incident is turned OFF, all new tickets will be logged as service requests.

  • All historical/old tickets will continue to be of the old type and will therefore have the prefix that was set before the change. Whenever historical tickets are updated by agents, the ticket type will be updated to the new type by default.

  • Any admin setting that specifically refers to the old ticket type (for example: workflow is triggered only when ticket type = "Case") will not work and needs to be re-configured.