Setting Up a New Ticketing Application

A step-by-step guide to setting up a new Ticketing application, covering everything from creating the application and assigning user access to configuring forms, workflows, notifications, and Client Portal services.

Ticketing applications are Work Management (TDNext) applications that allow your team to manage incidents, service requests, problems, changes, and releases. Your organization can run multiple Ticketing applications — for example, separate applications for IT, HR, and Facilities — each independently configured with its own forms, workflows, statuses, SLAs, and user access. Users can hold different permission levels across applications, giving you precise control over who can see and act on tickets in each one.

Setting up a new Ticketing application involves several configuration steps. Some settings are shared across all applications in your environment; most are configured per application.

In this article:

• Create a New Ticketing Application
• Configure Application Base Settings
• Review Shared Settings
• Define Application-Level Security Roles
• Assign Users to Security Roles
• Configure Classifications
• Customize Forms
• Configure Statuses
• Configure Ticket Types
• Set Up SLAs
• Define Custom Attributes
• Configure Ticket Workflows
• Set Up Notification Templates
• Connect Client Portal Services

 

Only Global Administrators can create new Ticketing applications in TDAdmin.

To create a new application:

1. In TDAdmin, click Applications in the left navigation.
2. Click the +New button.
3. In the New Application window, fill in the fields:
   1. Name — Appears in reports and in the Work Management application menu. Keep it short, meaningful, and distinguishable from other applications.
   2. Description
   3. Type — Select Ticketing Application.
   4. Icon — Appears on the Work Management Applications tile.
4. Click Save.
5. In the Applications list, click the new application's name to open its settings.

Each Ticketing application has a Settings page where you configure core operational behavior: default statuses, notification preferences, Client Portal visibility, and ticket lifecycle automation. These settings apply across the entire application.

See Configuring Ticketing Application Base Settings for details.

Note: The following settings are configured once and shared across all Ticketing applications in your environment. You do not need to set them up for each new application, but you should review them to confirm they meet your needs before proceeding.

• Impact, Urgency, and Priority
• Priority Matrix
• Sources
• Type Categories (a reporting construct used to group ticket types across applications; Type Categories can only be managed by Global Admins)

See Shared Settings Overview for details.

Application-level security roles control what technicians and other resources can do within a specific Ticketing application. Global Administrators and Ticketing Application Admins for the specific application can manage these roles.

See the Ticketing Application Permissions article for details on available permissions.

To define a new application-level security role:

1. Open the Ticketing application Admin page:
   • Ticketing Application Admins: In Work Management, open the Ticketing application, click the gear icon in the top-right corner, select Admin, then click Users & Roles > Security Roles in the left navigation.
   • Global Admins: In TDAdmin, go to Applications, select the Ticketing application, then click Users & Roles > Security Roles in the left navigation.
2. Click +New to create a new security role, or select the Default Security Role to modify it.
3. Give the security role a Name that follows your organization's standard and is easily identifiable.
4. Select the License Type appropriate for the role.
5. Select individual Permissions, or click Select Defaults.
6. Click Save.

See Getting Started with Security Roles for details.

Only Global Administrators can add users to application-level security roles.

1. In TDAdmin, go to Applications > [Ticketing application] > Users & Roles > Users.
2. Click Add.
3. Use Search to find each user, check the box next to their name, then click Insert Checked.
4. Select the Security Role.
5. To make a user a Ticketing Application Admin, check Add as Application Administrator(s).
6. Click Save.

Tip: If you granted yourself access to a new application, sign out and sign back in to update your security permissions and see the application in Work Management.

Each Ticketing application includes six default classifications: Service Request, Incident, Problem, Change, Major Incident, and Release. Classifications organize tickets and drive default form assignments — when a ticket is created, it automatically inherits the classification of its form.

Review the available classifications, customize the names to match your team’s processes, and disable any that your team does not use. Each classification is paired with a default ticket form, though you can assign any shared form to any classification.

See Configuring Ticketing App Classifications for details.

Ticket forms are fully customizable and control what information is collected when a ticket is created. Customers use forms in the Client Portal to submit requests; technicians use them in Work Management to create tickets; and the Email Service can also use them to create tickets.

Each classification has a default form assigned. You can use the shared default forms, customize them, or create new forms tailored to specific request types. When a ticket is created, it automatically inherits its form's classification. Changing a form's classification does not affect existing tickets, and changing a ticket's form does not change its original classification.

See:

• Creating and Managing Ticketing Forms
• Configuring Default Ticket Forms for Each Classification

Each Ticketing application has its own set of ticket statuses, which track a ticket's progress through its lifecycle. TeamDynamix includes seven built-in default statuses organized into five status classes: New, In Process, Completed, Canceled, and On Hold. You can customize existing statuses or add new ones to reflect your team's workflows.

See Configuring Ticket Statuses for details.

Ticket Types specify the kind of work to be performed on a ticket. Create a new ticket type when different work requires a distinct reviewer, time types, or group permissions.

When you save a new ticket type, additional tabs appear for configuring Time Types, Expense Accounts, and Groups. The Groups tab lets you restrict which groups can use a type — you can allow only selected groups, or allow everyone except selected groups.

Optionally, you can associate a ticket type with a workspace. When actual hours are logged on tickets of that type, those hours accrue toward the workspace, supporting resource management for non-project-based work.

Note: Ticket Types are organized into Type Categories, which are a shared setting used across all Ticketing applications and projects. Type Categories can only be managed by Global Admins.

See:

• Getting Started with Ticket Types
• Adding Time Types to Ticket Types
• Managing Ticket Type Expense Accounts

Service Level Agreements (SLAs) define the expected response and resolution times for tickets in this application. SLA requirements can be configured per Ticketing application and can be based on a 24/7 calendar or your organization's operational hours. Escalation steps can be added to each requirement to trigger ticket events or notifications when a deadline approaches or is missed.

See Managing Ticketing Service Level Agreements (SLAs) for details.

Custom attributes are additional fields you add to ticket forms to capture information specific to your team's workflows — for example, the type of device a user is having trouble with, or a location and room for a facilities request.

Custom attributes are defined at the application level and can be associated with specific ticket types or left unassociated to make them available to all types.

Attribute types include text boxes, text areas, date pickers, date/time pickers, dropdowns, multiselects, checkbox lists, radio button lists, yes/no dropdowns, person lookups, asset lookups, configuration item lookups, color pickers, and location fields.

See Managing Ticketing Custom Attributes for details.

Ticket workflows automate the approval and fulfillment process that a request must go through. A workflow can include a range of step types — getting approvals, evaluating conditions, sending notifications, and making automated decisions — to enforce structured processes without manual intervention.

A workflow can be assigned to a ticket automatically (when triggered by a service in the Client Portal or by an automation rule) or manually via the ticket's Actions menu. When a ticket is automatically assigned to a workflow during creation, its classification is always set to Service Request.

Common uses:

• Change management approval processes.
• Multi-level authorization requirements.
• Conditional routing based on ticket attributes.
• Automated notifications at specific process stages.

See:

• Configuring Ticket Workflows
• Assignment and Operation of Ticket Workflows

Ticketing notifications keep stakeholders informed of ticket progress via email. Notifications can be sent to the requestor, the creator (if different from the requestor), a contact on the ticket, the responsible resource(s), or the ticket reviewer.

All notification templates come pre-populated with default content. You can customize templates for each Ticketing application; if a template hasn't been customized, the default content is used.

See Managing Ticketing Notification Email Templates for details.

When ticket forms are made available through the Client Portal Service Catalog, end users can submit requests that automatically generate tickets in your Ticketing application. This creates a self-service experience while ensuring that all necessary information is captured.

Forms can be configured for public access, allowing unauthenticated users to submit requests without logging in — for example, a public Password Reset service for employees who have forgotten their credentials or vendors without system access. By default, workflows are not applied to tickets submitted by public users, but you can enable specific workflows to run on tickets created by public forms.

Forms can also be shared outside the Client Portal via a direct link or embedded on another page using an iframe.

See Using Ticketing Forms in the Service Catalog for details.