In this guide we will cover:
– What are Ticket Types?
– Creating a Ticket Type
Admin Guides:
Related Guides:
Note: We cover a lot of the most used settings in this guide, but there are a lot more options. For detail on what each setting here does, check out the linked admin guide.
What are Ticket Types?
Ticket types are individual kinds of ticket that can be created for different purposes within Halo. It is a way of categorising your tickets as well as by setting ITIL types against a certain ticket type.
Creating a Ticket Type
Head to Configuration > Tickets > Ticket Types.
Fig 1. Ticket Types configuration.
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.
The "Details" tab will open by default.
- Give your new ticket a name ("Ticket Type Name") and set the ITIL type ("ITIL Ticket Type").
- Set the "Use" to Tickets.
- The check-boxes below this can be amended as you need based on who you want to have access to this ticket type.
- Ticket Groups
- Tickets General Settings in Detail
Fig 2. Details tab on a ticket type.
The next tab is the "Defaults" tab. This is where you set the "Initial Status" of the ticket when it is first opened, and whether the ticket should automatically start a workflow or approval process.
You will also need to set the team/agent it should be assigned to by default, and the email "From Address" to use.
Fig 3. Defaults tab on a ticket type.
The "Forms" tab is next, which can be used to customise how the ticket is logged by end-users in the self-service portal, as well as how the ticket appears on the agent portal. For instance to show the "Audit Log" tab, enable "Display the Auditing Tab". This will show all changes made to that ticket by both system and agents, which will allow you to understand when/why a change was made.
Fig 4. Forms tab on a ticket type.
The "Field List" tab is where fields can be added to the ticket type – both custom and system. Just click the "Add" button and select some from the dropdown list. Below, the "Asset" field has been added for example, which will allow agents to link related assets to the ticket.
Fig 5. Field List tab on a ticket type.
Clicking the pencil icon on a field will allow you to edit the field visibility. You can set whether it shows for agents and/or users, and whether it is mandatory.
- 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
It then works similarly for Agent visibility.
Fig 6. Setting if the field is mandatory/visible.
Scrolling down on the popup will show the options for dynamic visibility.
- Dynamic Field Visibility – This field will only show based on the conditions set here based on another field.
- Dynamic Field Value Visibility – Values within this field will only show based on the conditions set here.
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.
Fig 7. Dynamic visibility options.
If creating a new ticket type, the "Layout" tab will appear greyed out. It will become available once the ticket type has been created and saved. This will automatically be set to "Default", but if you wish to move around the order of the tabs on the ticket type, set this to "Custom" where you can drag-and-drop to rearrange, or edit to hide tabs.
You will also noticed that once saved, the option for "Access Control" appears in the buttons at the top. Here, administrators can grant access for other agents to be able to modify the configuration of the specific ticket type. This is a useful feature so that managers can edit the ticket type that their team uses without having to ask the administrator to do it foe them.
Fig 8. Layout tab.
The "Allowed Values" tab dictates which statuses, actions, etc, are available for use on the ticket type. If checked to allow all, the only restrictions will be by agent permission or the workflow. If unchecked, a table will appear where you will have to manually add each value you wish to allow.
Fig 9. Allowed Values tab on a ticket type.
The final tab, "Settings", is where the status after action, closure, and email settings are configured.
The "Status After Action" sets what the status of the ticket will be after certain people respond, i.e. "Status after End-User update" is usually set to "Updated" to show agents that the user has responded.
Fig 10. Settings > Status After Action on a ticket type.
Further down is the "Email" section. The key settings here are whether you enable SLA hold reminders, enable account manager emails, or if the ticket CCs in followers.
Fig 11. Settings > Email on a ticket type.
Scrolling down a bit further is where the "Closure settings" are contained. Here is where you can configure whether emails on closed tickets reopen them or not, whether children need to be closed to close the parent, or if you are using closure confirmation procedures.
Fig 12. Settings > Closure settings on a ticket type.
