HaloPSA

HaloPSA Guides

Documentation to assist with the setup and configuration of the HaloPSA platform

Guides > Altering Ticket Types

Altering Ticket Types

Creating a New Incident Ticket Type


Note: The location of some settings may differ if you are on an older version of Halo, the Ticket Type UI has been changed in the later versions, sorry for any inconvenience this may cause. The recommendation would be to check the admin guide on ticket types, for a comprehensive list of all settings along with their descriptions: Ticket Types


Head to Configuration > Tickets > Ticket Types

Click on an existing ticket type and "Edit" to change an existing ticket type, or click "New" to create a new one. The following details how to create a new ticket type but the same steps apply when editing:


  • Give your new ticket a name and leave the ITIL ticket type as Incident, unless this will be used elsewhere.
  • Set the "Use" to Tickets.
  • The check-boxes below this can be amended as you need based on who you want to have acces to this ticket type.
  • Ticket Groups
  • Tickets General Settings in Detail

The next block of settings determine the behaviour of the ticket when emails come in. These set the status of the ticket after the described event with "Emails on Closed Ticket" determining what happens when an end-user updates in and attempts to update a closed ticket. These settings now exist under the settings tab of a ticket type




After these settings are the following options which can be changed specific to yours and your organisations way of working, change these as you see fit. The setting "Apply defaults when Tickets are changed to this Ticket Type" Exists in the Defaults tab of a ticket type.


The "Apply Defaults" option (In the defaults Tab) would take effect when you switch the ticket type of an active ticket to this one. The "Automatically respond [...]" option is intended for situations where it can be assumed that an agent manually logging a ticket on behalf of the end user would have done so after two-way communication has happened (e.g. a phone conversation) with the user. In this case, you may wish to class that initial conversation as a response to the issue and log the ticket as responded to already.





Next, the defaults tab. These options take effect when a ticket of this type is created. These can all be changed on an active ticket. 


Next is the field list tab. This shows the list of fields to fill in when the ticket is generated by an Agent (much like a form to fill in). When a ticket is logged, these fields and the data put into them will be visible within the ticket on one of the details panes or in a tab depending on your preference. Add the fields you deem necessary for this ticket type by clicking the + and then click the pencil to edit the field's options.



  • End-User New ticket - Visibility for new tickets raised via your End-User Portal
  • End-User Ticket Details - Visible on Existing tickets on End-User Portal
  • Similarly for Agent visibility - On the Agent Portal and the visibility options speak for themselves as you can have fields that are in the ticket that cannot be altered on creation.


Dynamic Visibility 


As described will only show the field if another is populated with a specific value. This can be used for creating a process whereby filling in one field makes another appear, this is useful when making a ticket type which acts as a questionnaire for example.


The allowed values tab allows you to specify a given set of Actions, Category Values and Statuses. If you are unsure simply leave this as is and all values will be permitted.


Auditing Tab 


You can also enable the auditing tab against ticket types for auditing purposes


NB: The auditing tab setting may show in the forms tab, depending on which version you are on.




This will then display an auditing tab against each ticket of that type as shown below:



The action outcome will also now appear within this audit tab on tickets. 

Popular Guides