Ticket Schema Configurations

Overview

With this feature, ticket schema-specific settings have been brought to the frontend. These can be configured by admin user roles or implementation teams.

There is no change in the list page. All the existing ticket schemas will be listed.

Association Rule: A ticket schema can be associated with one or more departments. However, a department can have only a single ticket schema associated to it.

Ticket Schema Settings

There are two sections to the settings: Basic Settings and Advanced Settings.

1. Basic Settings

Basic Settings has 3 subsections: Ticket Specifications, Watchers, and SLA Settings.

Ticket Specifications

This section contains all the primary ticket schema-specific properties.

Property	Description
Name	This is the ticket schema name. This is a mandatory field.
Description	This is the schema description. Users can add what the intention of adding this particular schema is (e.g., if this particular schema is intended to be applied for a specific department).
Bot name	Bot name to be used in email templates and reports. Each ticket schema can use a different bot name.
Ticket sequence	The pretext sequence that will be part of each unique ticket created as part of this ticket schema.Example: If the ticket sequence is `TKT0000`, then the tickets created would be `TKT0001`, `TKT0002`...Note: This is a mandatory and unique field. Since ticket IDs need to be unique, no two ticket schemas can have the same ticket sequence.
Reopen ticket	If enabled, we allow reopening of tickets for this schema. If enabled, users will have the option to add a limit on the number of times a single ticket can be reopened.
Acknowledgement message	Auto-response email when a ticket of this ticket schema is created. There is an additional option where users can include this message as part of the ticket comments. This is NOT mandatory.
Disable email ticketing	If enabled, email ticketing will be turned off even if email is configured.

Watchers

In this section, all watcher-specific configurations are added. Watchers are of two types:

Followers: Users from the ticket requester side who can track the ticket.
Collaborators: Users from the agent side who can help resolve the ticket.

How Watchers are Applied They can be added in three places:

Directly on a ticket: Agents can add users manually from the ticket details page.
As part of SLA: Users defined in the SLA policy are added when that specific policy applies.
Ticket Settings (This Configuration): Since an SLA policy can change for a ticket (depending on department, category, or subcategory changes), the watchers added via SLA can also change. However, the ticket schema is applied at the time of ticket creation and does not change. Therefore, watchers added here will always apply to a ticket once created.

Note: The interface for adding watchers here is the same as in the ticket details page and in the SLA policy.

Additional Setting: There is a toggle that allows these watchers to reopen tickets if enabled.

SLA Settings

These are SLA-related settings that are applied to the ticket.

SLA Breach Notifications Settings applied when SLA resolution escalation is approaching:

Notification threshold: At what point before the escalation should the first warning message be shown? (Input in hours).
SLA reminder frequency: How many times will the warning message be shown?
SLA reminder interval: The interval between each reminder message (Input in hours).
Default Breach Notifiers: The set of users who will be notified when there is a potential breach as defined above.

Response and Resolution Escalation The response and resolution escalations defined at the ticket schema level are fundamentally the same as those defined at the SLA policy level.

Fallback Logic: The ones defined here will be applied to a ticket if there is no SLA policy match. This ensures that all tickets are tracked and have definitive goals for ticket closure even if there is no SLA policy attached to it.

Additional SLA Configurations

Time Calculation: When enabled, ticket time calculation will be from the time of ticket creation even if a ticket is reopened.
Anonymous Agents: This setting allows customers to anonymize the names of the agents to the channel users (ticket requesters). If enabled, the user will have to provide the name that will be used instead of the actual agent's name.

2. Advanced Settings

These are additional optional properties that can be added to the ticket schema.

Working Shifts and Holidays

Date/Time Format: The format defined here will be used in ticket downloads.
SLA Timers: Timers are paused and resumed based on the defined working days, hours, and holidays. If a ticket is created in non-business hours (as per the timezone mentioned) or during holidays, the SLA timer will be paused.

Other Settings

Antivirus and Macro Scans: Internal scans of uploaded documents to ensure the dashboard is kept virus-free.
Ticket Creation Rate Limit: The time within which new tickets by the same user will be treated as duplicates or spam and will not be created.
Email Loop (Ticket Notification Rate Limit): Defined by Time (seconds) and Count. If more than the specified count of tickets are created in the specified time from the same ID via email, we do not send notifications. This prevents infinite loops in email ticketing.
Default Values for Extra Fields: User properties (fetched from the employee master) can be mapped to extra fields.

Example: If there is an extra field called Designation and we do not want the user to fill this manually, it can be removed from the ticket form and mapped directly from the user's designation field stored in the employee master.

Updated 10 days ago