This article will help TeamDynamix Administrators and Technicians understand some of the common questions/confusions within your ticketing application.
Overview
As a TDNext user, you may have questions while running reports, editing tickets, updating tickets, etc. This article touches on some of the more common questions we get about specific items within your Ticketing Application.
Difference between Being Primarily Responsible for a Ticket vs. Responsible for a Ticket
Primarily Responsible
Being primarily responsible for a ticket means that a particular resource or group (but not both) is assigned as responsible for the ticket record itself. Filtering searches or reports on primary responsibility means that only tickets where the specified resources or groups are marked as responsible for the tickets themselves will be returned. If a user is responsible for a ticket, the user's Primary Group will appear as the Responsible Group in any ticket reporting.
Responsible
Being responsible for a ticket means that a resource or group is either primarily responsible for the ticket OR is assigned to an active ticket task on that ticket. Filtering searches or reports on responsibility will return both:
- Records where the specified resources or groups are marked as primarily responsible for ticket
- Records where the specified resources or groups are assigned to active tasks on the ticket
Note that responsibility will only include active ticket tasks. An active ticket task is a task which is not dependent upon an incomplete predecessor task.
Currently Responsible
Being currently responsible for a ticket is the same as being responsible for it, with the exception that completed ticket tasks are excluded.
Group Assignment
We have improved our group responsibility and behavior on Tickets and Ticket Tasks. For more information on the new functionality, please see Related Articles.
Display of Edited Fields in the Ticket Feed
As a part of ticket editing, the ticket feed will display a list of how edited fields changed as a part of the modification. In most cases, these will be of the format: Changed FieldName from "OldValue" to "NewValue." However, certain fields are explicitly excluded from the generated feed text. The following ticket form fields do not currently include value change information in the feed:
If these excluded fields are the only ones being changed, then the feed will simply display Edited this TicketClassification. Otherwise, the list of all standard value changes will be displayed, and those specific fields will be excluded from the list.
When Tickets Automatically Convert to Service Requests
There are a handful of scenarios in TeamDynamix which will automatically convert an incoming ticket to a service request. If you are having trouble getting your tickets to auto-convert to service requests, check that they fit the criteria below.
Tickets will automatically convert to service requests when
- If they come in through the Web API application and have a service specified which has a workflow attached to it. This might be through API calls written in integration apps or the TeamDynamix Email Service.
Note that the specified service and workflow must be active and in the same ticketing application as the ticket being created for this to work. Furthermore, a requestor must be detected on the newly created ticket and matched to an existing person record in TeamDynamix before the ticket will be converted to a service request. This is due to the fact that the ticket workflow might have steps which are assigned to the requestor.
- If they come through the Client Portal and the default ticketing classification for the ticketing application is Service Request. It is also important to note that if a custom request form is being used and that custom request form has a specific classification set, the custom form value will be used instead.
- If a ticket is being created in TDNext tickets or the Client Portal service catalog which specifies a service which has a workflow attached to it. Note that the specified service and workflow must be active and in the same ticketing application as the ticket being created for this to work. Furthermore, for the TDNext case, the ticket being created will only convert to a service request if it is not being associated as a new parent for a set of existing tickets.
- Automation rules attach a workflow. If automation rules attached a workflow to a ticket, it will be converted into a service request.
All cases listed above are subject to the following rule:
If first step of the workflow being applied to a ticket promotes the ticket to a different classification, the ticket will not be converted to a service request.
Issues with Links in Ticket Comments
If links in ticket comments are not working, the most likely reason is that some form of punctuation was added immediately after the user finished pasting or typing the link into their comment. The system looks for the first space after "http"//" or "https://" in a link as a place to stop including characters in the link address. If the link is too long, the system will truncate it on ticket comments, making it difficult to tell if punctuation was included at the end of the link. It is best to always add a space if the logical placement of punctuation would normally be just after the last character of the link.
Edited Ticket Fields Reverting to Original Values
Why do ticket fields revert to the values set at creation when I edit and save a ticket?
This is something that can very easily happen with the existence of Hidden or Read-only fields. In this case, it is very likely that the form which created the ticket has the field set to either be Hidden or Read-Only in TDNext. Choosing either of these options for the TDNext side of a ticket will cause the field to be locked and essentially not changeable via the Edit page of a ticket in TDNext. While there are other controls for some edits, such as assigning a ticket to someone via Actions > Assign [Service Request/ Incident/ Problem/ Change/ Release], editing the ticket at any point will cause it to revert.
What can I do so this doesn't happen to my tickets?
Resist setting the value for TDNext visibility on a field in your ticketing form to Hidden or Read-Only unless you are fine with it not being able to be changed by a technician upon creation. While there may be many reasons for wanting a field to not be able to be changed, other fields do need to have the ability to be changed by technicians, so be aware of the settings you've configured for each field on each form.