Configuring Ticketing Application Base Settings

The status that is automatically assigned to tickets created without a status specified. Typically set to a status with the "New" status class.

When a requestor withdraws their own ticket request from the client portal, the ticket changes to this status. If no status is selected, requestors cannot withdraw their own requests. Must be a status with the "Canceled" or "Completed" class.

Sets the default value of the privacy checkbox in commenting and updating dialogs. The privacy setting can still be toggled for individual comments as needed.

Enable this setting to have comments created by technicians private by default (not visible to clients in the client portal), while still allowing them to make comments public when appropriate.

Automatic Contact Addition Options

• Add Contacts when users update or comment on a ticket – Automatically adds users who interact with the ticket as contacts, making it easier to communicate with them in subsequent updates
• Add Contacts from additional email recipients – When a ticket is created or updated by an email monitor or email reply monitor, any additional recipient email addresses will be added to the ticket as contacts (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 to add contacts.

• Automatically take tickets off hold when they are commented on- When enabled, tickets placed on hold will automatically be taken off hold when:
  • The ticket is commented on through the client portal
  • 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
• When automatically taken off hold, the ticket reverts to its last off-hold status or to the "Automatic Off Hold Status" (if configured), similar to when tickets are taken off hold by an automated timer.
• Automatic Off Hold Status - When an on-hold ticket automatically goes off hold (either when the "goes off hold" date is reached or when a user comments on it), the ticket will be set to this status. When left blank, tickets revert to the status they had before being placed on hold.
• Related Client Portal Application - The client portal application used by default when users search for knowledge base articles or services from within this ticketing application. Users with access to multiple client portal applications can still search other portals using the lookup pages.
  When users create new knowledge base articles from within this ticketing application, the articles are created in the selected client portal application. If "All client portals" is selected, the default client portal will be used for creating articles.

Controls what happens when someone interacts with a completed or canceled ticket. When tickets have a "Completed" or "Cancelled" status class and any of the following occurs, the system can reopen the existing ticket or create a new one:

• The ticket is commented on through the client portal
• 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

Choose one of the following options:

• Always reopen tickets - The ticket changes to the reopen status specified below
• Reopen tickets within [X] day(s) of completion/cancellation; create new tickets afterwards - Measured in calendar days
• Never reopen or create new tickets - No action taken
• Always create new tickets - Creates a new ticket with the default status, copying basic properties (including responsibility) and the text of the feed item that initiated the update; the requestor is notified

Note: Creating a new ticket rather than reopening can lead to more accurate reporting when requestors contact you about the same issue after a significant time has passed.

The status assigned when a ticket is automatically reopened. Must be a status with the "New" or "In Process" class.

Automatically moves tickets from one completed status to another after a specified number of days. This creates a distinction between "resolved" (pending confirmation) and "closed" (confirmed complete) tickets.

When this option is enabled, tickets with a "Completed" status class will automatically move to the specified completed status when all of the following conditions are met:

• The ticket's status has the "Do Not Reopen" setting turned off
• The specified number of days has passed since the ticket was completed
• The ticket's completed date is on or after the start date specified below

Choose one of the following options:

• After [X] day(s), update completed tickets to the [selected status] status
• Do not automatically update completed tickets

Note: Ticket timeframes run on actual hours, not the application's operational hours, so status changes can occur on weekends.

The start date for applying the automatic completed ticket status change. The minimum value is either the previously set date or today's date.

When tickets are created in Work Management, these settings determine the default state of notification checkboxes. Users can still toggle these settings for individual tickets.

• By default, notify the responsible resource that they have been assigned to the ticket
• By default, notify the requestor about the ticket

Controls when notifications are sent during the ticket lifecycle:

• Notify Responsible or Reviewer when a user comments on a ticket - Automatically notifies the appropriate Work Management user(s) when a comment is added to a ticket. Note: When this setting is enabled, the automatically notified resource is removed from the "Notify" dropdown list when leaving comments in the client portal.
  Notifications are sent in the following order:
  • If a responsible user or group is set, that resource receives the notification
  • If no responsible resource is set, the reviewing user or group receives the notification
  • If there is no responsible or reviewing resource set on the ticket, no notification is sent
  • Notifications are suppressed if the commenting user is the same person who would be notified
• Notify Requestor by default on ticket updates - Automatically adds the requestor to the notification field when updating a ticket. This can be cleared by the Work Management user if needed. 
•  Notify All by default on ticket updates - Automatically includes all available users for notification on the Work Management ticket update page. The user can remove recipients if needed. 
• Notify All by default on client portal comments - Automatically includes all available users for notification when commenting from the client portal. The user can remove recipients if needed. 

When ticket tasks are created in Work Management and becomes active, automatically send a notification to the responsible group members if:

• The group member is an active member of the group
• The group member has the "Include in Notifications" group setting turned on

These settings determine which users can view tickets in the client portal:

• Allow requestors/creators to view tickets in the Client Portal 
• Allow users in associated accounts/departments with the appropriate permission to view tickets in the Client Portal - Requires users to have the global security role permission "View all requests belonging to assigned accts/depts"
• Allow ticket contacts to view tickets in Client Portal

Note: Disabling these settings does not prevent users with direct access to this ticketing application (or through the "View All Application Instances in Analysis" global permission) from viewing tickets. Additionally, users assigned to workflow steps will still be able to view the associated ticket.

See the  Managing Ticket Visibility in the Client Portal article for information on applying these settings for your organization's scenarios.

Controls how workspace members can interact with tickets in this application if they do not have direct access to the application:

• Always allow workspace members to view tickets and ticket tasks that have been added to their workspace
• Always allow workspace members to assign responsibility for tickets and ticket tasks that have been added to their workspace 
• Always allow workspace members to edit tickets and ticket tasks that have been added to their workspace. This includes creating ticket tasks on tickets within the workspace 
• Always allow workspace members to update tickets and ticket tasks that have been added to their workspace

Tickets converted to project tasks have statuses that help track the ticket's status within the ticketing application. An automated process updates the ticket status based on the project task's percentage complete (a delay may occur between updating the task and the ticket status being updated).

There are three task status settings based on task completion percentage:

• Not Started Project Task Status – The task is 0% complete. This status class must be "New" or "In Process."
• Started Project Task Status – The task is 1-99% complete. This status class must be "New" or "In Process."
• Completed Project Task Status – The task is 100% complete. This status class must be "Completed."