This getting started article will help administrators or application administrators to create Ticket Types in the Ticketing application. The user must have the TDAdmin or application administrator access.
Overview
TeamDynamix offers many ways to categorize ticketing data, including by ticket type and type category. These categorizations help classify the nature of the ticket being created. Type Category is used to help categorize Ticket types that are the same “theme” or “subject.” One thing to keep in mind with configuration around Ticket Types is they are internal values to TDNext and Technician views. These are non-client facing value.
Where to Find This
Creating a Ticket Type
To create a new ticket type within a Ticketing Application:
- In TDAdmin, click Applications in the left navigation.
- Select the desired Ticketing Application.
- Click Types in the left navigation.
- Click the +New button.
- In the Type window, select a Category for the new ticket type.
- Enter a Name for the ticket type.
- Configure these remaining ticket type settings as desired:
- Primary Reviewer – The person or group who will first encounter a ticket (if unassigned upon creation) to ensure it gets triaged appropriately.
- Active Status – Marking a ticket type as inactive means that users will not be able to create new tickets of that type. This has no effect on any tickets that have already been created with that type. In addition, users will still be able to select deactivated types for reporting purposes.
- Notification of primary reviewer of new ticket types – If you choose to notify the primary reviewer, you must select a primary reviewer.
- Notification of responsible resource(s) when all tasks are complete - This works for both individual or group assignment. For tickets of this type with this setting active and a specific user assignment you will see this active function displayed on the ticket under the "My Alerts" tab. For group assigned tickets there is no display on the ticket indicating this alert is active.
- Workspace – When a workspace is selected on a Ticket Type, any time entered on tickets of this ticket type will be applied not only to the ticket itself, but also toward the selected Workspace.
- Notify other email addresses
- Default Task Template - The default task template specifies the set of tasks that is automatically added for each ticket (of this type) created via the Requests application and web services. In the main Ticketing Application, individuals can specify a different task template on creation but the specified task template will be selected by default when this type has been selected.
- Default SLA – If a type is assigned a default SLA, all tickets that are not created through a custom form will be assigned to this SLA by default. However, when creating a ticket through the Ticketing Application, users who have the Change Service Level Agreements of Tickets permission will be able to choose the SLA from a list.
- Click the Save button.
To modify or edit the options on a ticket type, navigate to the Ticketing Application > Types page, and click the Name of the ticket type to edit.
Deleting a Ticket Type
You cannot delete a ticket type if there are any tickets, services, or email monitors associated with it.
To delete a ticket type from within a Ticketing Application:
- In TDAdmin, click Applications in the left navigation.
- Select the desired Ticketing Application.
- Click Types in the left navigation.
- On the Types list, locate the desired type and click the Delete link at the far right end of the row.
- Click the Delete button.
- Confirm the deletion in the popup.
Categorizing Tickets: Type Categories, Ticket Types, and Services
TeamDynamix offers many ways to categorize ticketing data:
- Type category
- Ticket type
- Form
- Service category
- Service
- Custom attributes you define
Defining your categorization data is also closely aligned to building your service catalog. See the ECAR section below for more information.
Conceptually there are several types of service catalogs:
- Lines of service catalog (historically called the Business Service Catalog by ITIL) – The primary audience for this catalog is the cabinet/executives and the Board. This catalog justifies why IT exists and is at a high level.
- Service catalog – The primary audience for this catalog is your customers, to use ITIL's term, which means people with the ability to purchase services. In higher education customers are often department heads. The service catalog should describe the parameters of the service, e.g. hours of operation.
- Service request catalog – The primary audience for this catalog is your end users. The service request catalog should be actionable. This is the primary function of TeamDynamix's service catalog.
Using Educause Type Categories
Please read the ECAR paper on building a service catalog. Note the terms that paper uses for service category, service, and service offering. The ECAR paper uses terms that mean different things in TeamDynamix.
Populate your TeamDynamix type categories with the service categories outlined in the ECAR paper. Consider using the categories outlined on page 17 of the paper: Administrative and Business, Communication and Collaboration, etc.
Populate your TeamDynamix ticket types with the services outlined in the ECAR paper. See pages 18-22 of the ECAR paper.
Populate your TeamDynamix services with those found in the ECAR paper's service offerings.
Other Categorization Data
- TeamDynamix Service category – You can also choose to use TeamDynamix service categories. However, TeamDynamix service categories are defined as the immediate category in which the TeamDynamix service is placed, and their primary purpose is to help you organize your TeamDynamix services so they are easier to find for end users.
- Form – You can report on tickets by the form that was used. However, one form can be used for several different services. Additionally, forms are classification-specific, so they sit under classifications e.g. to help drill down into your incidents.
- Other custom attributes – You can record other attributes as you see fit. Any time you create a custom attribute, please reflect on whether an out-of-the-box attribute might fit your needs.
Reassociating Tickets from One Type to Another
Use with caution, this action cannot be undone.
Administrators can reassociate all tickets of a particular type to another type. This is especially useful when trying to delete a ticket type, as a ticket type cannot be deleted if there are existing tickets of that type.
Note that if you were to change a ticket’s type, the SLAs and Task templates applied prior to the change will remain active. Any SLAs or Task Templates associated with the new ticket type will not be applied.
Also, once you reassociate tickets from one type to another, this cannot be undone. Ensure that you choose the correct types when performing this action.
To reassociate all tickets of one type to a new ticket type:
- In TDAdmin, click Applications in the left navigation.
- Select the desired Ticketing Application.
- Click Types in the left navigation.
- Click the title link of the Ticketing application that you’d like to reassociate in the Reassociate from Type field.
- Select the ticket type you would like the affected tickets to be reassociated to in the To Type field.
- Click the OK button when asked to confirm that you want to reassociate tickets from the old type to the new one.
Gotchas and Pitfalls
- When a user changes a ticket's type the SLAs and Task templates applied prior to the change will remain active. Any SLAs or Task Templates associated with the new ticket type will not be applied.
- If using the "Notification of responsible resource(s) when all tasks are complete" setting: once the alert notification for tasks completed is served on a ticket the alert is removed from that ticket. Meaning if all tasks are completed and a notification goes out then another task is added after the alert goes out the alert will not apply to those subsequent tasks. You would need to manually add the alert again for an individual on the "My Alerts" tab or edit the ticket type to a different type and return it to the original type to 'reset' the alert.