This getting started article will help TDX Administrators to adjust ticketing application settings using the TDAdmin interface. The user must have either TDAdmin access in TDAdmin or be an Application Admin in TDNext.
Overview
Each Ticketing Application has several unique settings that allow some options to be configured differently in each instance of the application.
Where to Find This
This feature appears in the TDAdmin interface.
TDAdmin is where these settings are configured, and TDNext is where these settings appear.
Navigate to Ticketing Application Settings following these paths:
- TDAdmin > Applications > Ticketing Application > Settings
- TDNext > Ticketing Application > Blue Gear Icon (Upper Right Corner) > Admin > Settings
Where to Start
Modifying Ticket Settings
To modify ticket settings:
- In TDAdmin, click Applications in the left navigation.
- Select a Ticketing Application.
- Click Settings in the left navigation.
- Modify the desired settings.
- Click the Save button.
Available Ticket Settings
The following settings are available:
- General Settings
- Default Status – The selected status is automatically set on any tickets that are created without a specific status. This is usually a status with the New status class.
- Requestor Withdrawn Status – When a requestor withdraws a ticket request on the client portal, it will be set to this status. If no status is selected for this ticketing application, then Client users will not be able to withdraw ticket requests. This status must be of the class Canceled or Completed.
- Comment Default – The default privacy setting will be when applying a comment on a ticket in TDNext. The privacy setting can be toggled on every comment as needed, but this decides the default setting.
- Automatic Contact Addition Options
- Add Contacts when users update or comment on a ticket - This setting automatically adds users who interact with the ticket as contacts on the ticket, making it easier to communicate with those users in further updates.
- Add Contacts from additional email recipients – When a ticket is created or updated by an email monitor or email reply monitor, if there are any additional recipient email addresses on the email, they will be added to the ticket as a contact (if a record exists for them).
- Note - When an email reply monitor updates a ticket, the email reply monitor user must have access to the ticketing application in order to add contacts.
- On Hold Options – When tickets have been placed on hold and this option is checked, they will automatically be taken off hold when any of the following conditions happen. When a ticket is automatically taken off hold, it will revert to the last off hold status it held, similar to when tickets are taken off hold by an automated timer.
- The ticket is commented on through the Services application
- The ticket (or a related ticket task) is commented on through email
- A feed item on the ticket (or a related ticket task) is commented on
- Automatic Off Hold Status - When selected, if the system automatically takes a ticket off hold, this status will be set on the ticket. When blank, tickets will return to the status they had before they were placed on hold.
- Related client portal application – When searching for articles, services or service offerings, or creating articles from within a ticketing application, the selected client portal application will be used by default.
- Ticket Resolution/Closure Settings
- Reopening Completed/Cancelled Ticket Options – What action should occur when a ticket is reopened? Requestors might call in regarding the same incident, but you may prefer it is created and tracked as a separate incident. Creating a new ticket can result in more representative reporting data. This is measured in calendar days.
- Reopen Status – When a ticket is automatically reopened, it will be set to this status.
- Completed Ticket Options – These settings allow you to automatically move tickets from one completed status to another after a specified number of days. This can be used to create a distinction between resolved tickets and closed tickets, where resolved tickets are pending confirmation from the requestor for the specified number of days before they are automatically closed. Ticket timeframes are not based on the application's operational hours, but instead run on actual hours (i.e., a ticket can have a status move occur on a weekend).
- Notification Settings
- Ticket New Settings – When tickets are created in TDNext, these settings determine whether the checkboxes to notify the requestor and responsible resource are checked by default. The user can still toggle these settings on individual tickets as they are created.
- Automatic Notification Options – These settings determine when notifications will be sent during the ticket lifecycle
- Notify Responsible or Reviewer when a user comments on a ticket - This will automatically notify the appropriate TDNext user(s) when a comment is added to a ticket.
- Notify Requestor by default on ticket updates - When checked, this adds the requestor to the notification field automatically when updating a ticket. This can be cleared by the TDNext user if needed.
- Notify All by default on ticket updates - When checked, the ticket update page will automatically include all available users for notification. The user can remove people if needed.
- Notify All by default on client portal comments - When checked, the client portal ticket comment page will automatically include all available users for notification. The user can remove people if needed.
- Ticket Task Notifications – When ticket tasks are created in TDNext, these settings determine whether or not the responsible group is notified.
- Notify Responsible Group when Task becomes active - If the "Notify Responsible Group when Task becomes active" setting is enabled, a notification will automatically be sent to the responsible group members of that task when it becomes active if the group member is an active member of the group and the group member has the "Include in Notifications" group setting turned on.
- Client Portal Visibility Settings – These settings determine which users can view a ticket in the client portal.
- External User Settings
- Workspace Settings - These settings determine how workspace members can interact with tickets in this application if they do not have access to the application.
- Move Ticket Settings - These settings determine whether users can move tickets into this application without having access to the application.
- Task Statuses – Tickets that have been converted to Project Tasks inside the Project Management application have statuses to help track the status of the ticket inside the Ticketing application. Each of these statuses follows status class rules for tracking the status of tickets that have been converted to project tasks. There is an automated process responsible for updating the status of converted tickets, so there may be a delay between updating the task and the ticket status being updated to reflect % complete.
- Not Started – The task is 0% complete. This status class must be New or In Process.
- Started – The task is 1-99% complete. This status class must be New or In Process.
- Completed – The task is 100% complete. This status class must be Completed.
- There are three Task Status settings which are based upon % complete of the task:
Gotchas & Pitfalls
If unsure of which settings to enable, always use the default ticketing application Settings. These are a good starting point for a go live or an initial launch of the ticketing application. Over time it is recommended to review these Settings to determine if changes are needed.
Examples
The Make comments private by default (only visible to Tickets users) is a great setting to enable if you would like for Technician by default to create private comments which are not visible to the client in the Client Portal. Please note that this check box can still be enabled if needed.