Body
Who can use this feature?
- License Requirement: Technician or higher
- Application Access: Work Management and the specific Ticketing application
Tickets in TeamDynamix are used by technicians to restore service to users who have experienced issues (incident management), fulfill service requests, and handle problem, change, and release management processes.
When users experience service interruptions or need assistance, they submit requests through the Client Portal's Service Catalog, by email, or by contacting the service desk. Tickets are created for these requests in the appropriate ticketing application, where technicians can process them, track progress, and restore service. Technicians can adjust ticket classifications as needed to match the type of work being performed.
In this article, we'll cover:
As an End User
Client Portal > Services / Ticket Requests
- Submit new service requests
- View and comment on existing tickets
- Track request status
As a Technician
Work Management > [Ticketing Application]
- View assigned tickets
- Update ticket status and details
- Add time and comments
Work Management > My Work
- See all assigned work across applications
- Quick access to tickets requiring attention
Your Ticketing Application Dashboard
When you open a Ticketing application, you will land on your Ticketing application dashboard. The dashboard provides a customizable view of your Work Management data specific to that application. You can add standard widgets for common data views as well as custom searches and reports you have created. If you have not yet configured it, the page may appear blank when you first access it.
To edit your Ticketing dashboard, click Edit Dashboard in the top-right corner of the application homepage.
Learn more in Getting Started with My Work and Creating and Managing Dashboards.
There are five ways that a ticket can be created:
- A customer can initiate a service request in the Service Catalog, creating a ticket. Ticket Requestor Quick Start Guide
- A customer can email the service area, triggering the creation of a ticket via the Email Monitor.
- A customer can contact the service area through other means, prompting a technician to create a ticket in Work Management. Creating Tickets in Work Management
- A technician or admin can import tickets in bulk. Importing Tickets
- A technician or admin can make a call to the API to create ticket(s).
Note that bulk import and API methods are not utilized often.
As soon as a ticket has been created, Automation Rules will run. The only exception to this is imported tickets, which do not use Automation Rules.
Automation Rules are a preconfigured series of steps that fire when a ticket is created. These rules can automatically:
- Assign the ticket to a person or group
- Apply a workflow
- Assign a Service Level Agreement (SLA)
- Set specific attribute values
- Send notifications
A ticket can be assigned to a group, a person, both a group and a person, or to no one (unassigned). Ticket responsibility may be changed at any time during the ticket's lifecycle. Technicians with the appropriate permissions can take primary responsibility for unassigned tickets or reassign tickets to other technicians or groups as work requirements change.
Tickets can be assigned in several ways:
- Group assignment makes the ticket visible to all members of that group. This works well when multiple technicians have the expertise to handle a request, when the right individual hasn't yet been identified, or when you're routing work to a specialized team.
- Individual assignment designates a single person as the primary responsible party. Use this when a specific technician has the expertise or context needed, when escalating to a subject matter expert, or when clear accountability is required.
- Combined assignment — assigning both a group and an individual — keeps the ticket visible to the broader team while designating one person as the lead. The individual is the primary responsible party; the group assignment maintains team visibility.
- Unassigned tickets remain in a queue until a technician takes responsibility. While this is sometimes appropriate for intake queues, tickets should not remain unassigned indefinitely.
See Assigning and Taking Ownership of Tickets for more details.
After a ticket is created, a technician or a team of technicians will update it. Common reasons to update a ticket include:
- Changing the Status - Update the status to indicate where the ticket is in its lifecycle (New, In Progress, On Hold, Resolved, Closed)
- Notifying the Requestor - Communicate progress, provide information, or ask follow-up questions
- Adding Internal Notes - Document work performed or share information with other technicians
- Recording Time - Track time spent working on the ticket for reporting and billing purposes
While the technician updates and comments on the ticket, the client/requestor can view and comment on it in the Client Portal.
When updating a ticket, technicians can add comments that are visible to the requestor in the Client Portal. These external comments keep requestors informed of progress and maintain transparency throughout the resolution process.
Technicians can also add internal notes that are only visible to other technicians with access to the ticketing application. This allows teams to document troubleshooting steps, share technical information, or coordinate work without exposing internal details to requestors.
Though less common than updating, a technician may edit a ticket when:
- The client submitted the ticket using the incorrect form
- The service on the ticket needs to be changed
- The requestor needs to be changed or added
- Custom attribute values need to be modified
Editing permissions may be limited based on whether the technician is the primary responsible party or has broader edit permissions for all tickets.
When work on the ticket is complete, the technician updates it to Resolved, Closed, or another status that reflects its completion.
The distinction between Resolved and Closed status varies by organization, but commonly:
- Resolved indicates the solution has been provided and is awaiting confirmation from the requestor
- Closed indicates the ticket is completely finished with no further action required
See the
Updating Tickets article for more details.
In many cases, a ticket may be created for a more complex piece of work that requires a series of smaller steps to be completed before the ticket can be closed. Similarly, there may be situations where multiple teams must complete different parts of a ticket’s work.
Ticket tasks are subtasks added to a ticket to engage others or groups in contributing to the ticket, while the ownership and primary responsibility for the ticket remain the same.
When to Use Ticket Tasks:
- Breaking down complex work into manageable steps
- Engaging multiple teams or individuals in different aspects of the work
- Tracking completion of sequential steps in a process
- Maintaining accountability for specific portions of the overall ticket
Some ticket templates or forms may automatically add ticket tasks to new tickets, or you can add them manually through the Ticketing application in Work Management. Tasks are added to a ticket by the responsible party.
Best practice: Assign tickets to the owning group and keep them with that group, using tasks to coordinate work with other teams as needed.
See Getting Started with Ticket Tasks for more details.
A workflow can include a range of step types that serve different functions within a ticket. This may include getting approvals, evaluating conditions, sending notifications, and making choices, all to automate and enforce processes.
Workflows guide tickets through structured processes that require multiple steps, decision points, or approvals. Unlike ticket tasks, which represent work to be completed, workflow steps represent stages in a business process.
Common Workflow Uses:
- Change management approval processes
- Multi-level authorization requirements
- Conditional routing based on ticket attributes
- Automated notifications at specific process stages
See the
Assignment and Operation of Ticket Workflows article for more details.
Parent-child ticket relationships allow you to connect related tickets across different classifications within TeamDynamix. This hierarchical structure enables you to manage complex incidents, problems, changes, and releases more efficiently by grouping related work and cascading updates from parent tickets to all associated children.
When to Use Parent-Child Relationships:
- Linking multiple incidents to a single problem ticket
- Connecting related changes to a release
- Managing major incidents with multiple component incidents
- Tracking work that spawns additional related tickets
See Getting Started with Parent / Child Tickets for more details.
Scheduled tickets automate the creation of recurring work items on a defined schedule. This feature helps teams track routine maintenance activities, regular inspections, and other cyclical tasks without manual ticket creation.
Each ticketing application can have multiple scheduled tickets configured independently. Once set up, tickets are automatically created according to your specified schedule using a predefined ticket template.
Benefits of Scheduled Tickets:
- Automatically create tickets for routine maintenance or recurring work
- Ensure consistent tracking of cyclical tasks
- Reduce manual effort in ticket creation
- Maintain accurate records of scheduled activities
Learn more about Scheduled Tickets.
Service Level Agreements can be set up for tickets, establishing timelines that give technicians deadlines for responding to the requester and restoring service.
How SLAs Work:
- SLAs establish response and resolution timeframes based on ticket priority
- Timelines help ensure service interruptions are addressed promptly
- Requestors are informed of expected resolution times
- SLA violations can trigger notifications to management
SLAs often use the ticket's priority (calculated from impact and urgency) to determine appropriate response and resolution timeframes. Higher-priority tickets receive shorter timeframes, ensuring critical issues receive immediate attention.
Learn more about assigning SLAs to tickets.