Triggers are automatic processes that perform actions in response to ticket events.
A given trigger can respond to one of these three event types:
New Ticket - a new ticket is created
New Reply - an agent/user replies to a ticket
Ticket Update - a ticket property changes
You can see your helpdesk’s triggers at Tickets > Triggers - there is a separate subsection for triggers with each event type.
When an event happens, the triggers for that event type run in order, from the top down.
Most of the automatic processes that the helpdesk carries out, such as sending out notification emails, are controlled by triggers. You can edit the triggers to control exactly how your helpdesk operates.
Trigger event filtering
A trigger can be set to respond only to certain events within its event type, based on:
whether the event was carried out by a user or agent (or an app).
whether the event was triggered from the web interface, or email, or the API.
Click the gear icon next to By a user > via the web to further refine by the particular web interface.
Portal means the user web portal
Feedback and Support Tab is the embeddable widget (see under Portal > Embed)
Contact form means the embeddable Contact Form (see under Portal > Embed)
The via the API setting applies to events carried out by software that has been integrated with Deskpro. The API may carry out actions as a specific account. (See the API documentation for details).
Trigger criteria
Before a trigger performs its actions, it checks its criteria. The trigger’s actions will only be carried out if the criteria are met.
Criteria define conditions that must be met for the trigger to run. They may require that a particular ticket property is or is not a certain value. Depending on the property and event type, other comparisons can be available; for example, they may require that a value is not set, or that it has changed, or that it matches a regular expression, etc.
There are some installable apps which can respond to external events from other services. For example, if you install the JIRA app (which integrates Deskpro with JIRA issue tracking software), you can create triggers which respond to changes from JIRA.
Trigger order and trigger control
The triggers are checked in the order they are listed, with the top trigger first. You can drag triggers by the handles at the left to change the order.
In the example above, the Check email validation trigger runs, then Check agent validation, and so on.
There are trigger control criteria and actions which you can use to affect the usual trigger order.
For example, the Check email validation trigger runs the Stop processing triggers action if the user’s email hasn’t been validated, and this stops any triggers lower down from running.
The Trigger control actions available are:
Stop processing triggers
Prevent emails to user
Prevent emails to agents
Force agent email subscriptions
Set trigger variable
The Trigger control criteria available are:
Check if user was emailed
Check if agents were emailed
Check trigger variable (check the variable set by a ‘set trigger variable’ action)
Check current agent (this checks if the agent(s) specified caused the event through the agent interface, portal or via email)
Check performer email (this checks the email address of the person - user or agent - who caused the trigger event)
Note that the value of a trigger variable is only stored for the duration of the event.
Triggers with a stop processing triggers action are marked with a ‘broken chain’ icon, to remind you they can break the usual trigger order.
Bear in mind that the trigger control actions only apply to the current event. For example, suppose a ticket is updated, and the first Ticket Update trigger which runs applies a Prevent emails to useraction; no emails will be sent as a result of that particular ticket update event, but that will not stop emails being sent to the user as the result of future events.
Department and Email Account triggers
DeskPRO has built-in Department and Email Account triggers.
These simple triggers have fixed criteria, which you can’t edit.
Department Triggers: each department on your helpdesk has a New Ticket trigger which runs when a ticket is created through any means except email: either through the agent interface, the web portal, or an embedded form or widget.
These triggers link tickets submitted through the web to an email account; for example, tickets submitted to your Sales department have their messages sent from your
sales@account because of a department trigger.
There is also a Ticket Changed Trigger that applies when a ticket is moved into each department. This has no actions by default. If you want the email account used to send messages about a ticket to update when the ticket’s department is changed, you can use this trigger.
For example, suppose you have a
support@account linked to the Support department; by default, if a user submits a ticket tosupport@, then an agent changes the department of the ticket to Sales, the agent will continue to receive ticket emails from yoursupport@address. If you wanted the user in this situation to start receiving messages from yoursales@account, you could accomplish this with the Sales department Ticket Changed Trigger:
You can view and edit the simple Department triggers from Tickets > Departments as well as Tickets > Triggers.
Email Account triggers: each account you have configured to receive tickets has a simple trigger which runs when a new ticket is created via email.
These triggers link your email accounts to departments by assigning all new tickets created via an account to a specified department. For example, emails sent to your
sales@account create tickets in the Sales department because of an email trigger.
You can view and edit the simple Email Account triggers from Tickets > Email Accounts as well as Tickets > Triggers.
By default, a new helpdesk doesn’t send an auto-response email to the user to acknowledge a new ticket.
You can quickly enable an auto-response email to the user using the Send User Email action from a Department or Email Account trigger. The default New Ticket Auto-Response email template sends the user a simple acknowledgement message.
Default triggers
Aside from the built-in Department and Email Account triggers, your helpdesk comes with a set of default triggers.
You can edit these to change the behavior of your helpdesk.
Be careful about changing these default triggers. Editing may prevent users or agents receiving important notifications.
For reference, here are the default triggers and what they do in the helpdesk:
New ticket:
Enable email validation (off by default)
If this trigger is on, new users who submit a ticket have to prove they’ve supplied a valid email address by clicking a link in a confirmation email.
By default, this trigger applies only to tickets created by the user via web or email. If an agent creates the ticket, the trigger doesn’t run and validation is not required.
The email validation for new users setting in User registration is another view of this trigger. Changing one will change the other.
The trigger criteria simply checks if the user is new, then applies the special Require User Email Validation action.
When this action runs, it only records that validation is required. The trigger below is what sends the email with the validation link. If you have this trigger enabled, make sure the next trigger is also enabled, otherwise the user will never receive the email and won’t be able to validate their address
Check email validation (on by default)
This trigger checks if email validation is required (as set by the trigger above).
If the user has not yet validated their email address, the trigger carries out these actions:
Sets the status to “awaiting validation”.
Sends out the email with the link that the a user must click to validate their email address. This email uses the New ticket requires validation (auto-response) template.
Stops processing triggers (so agent notifications etc. will not be sent until the user validates).
Note
This trigger is on by default, but it won’t do anything unless the previous trigger is enabled.
Check agent validation (on by default)
Checks if the user is waiting to be manually validated by an agent. This can only happen if that option is enabled under CRM > Registration.
By default, this trigger applies only to tickets created by the user via web or email. If an agent creates the ticket, the trigger doesn’t run and validation is not required.
If validation is required, the trigger carries out these actions:
Sets the status to “awaiting validation”.
Stops processing triggers (so agent notifications etc. will not be sent until an agent validates the ticket).
Send agent notifications (on by default)
Sends out email notifications of a new ticket to agents (depending on their notification settings). Uses the New Ticket Notification template by default. You can customize the name and account used to send the email.
Note
You can control the notifications each agent receives in Admin > Agents without editing this trigger. Agents can also edit their own notifications from Preferences in the agent interface (provided they have the right permissions).
Send auto-reply confirmation to user (off by default)
Sends out an auto-response acknowledging that the user’s ticket has been received. You can customize the name and account used to send the email.
Send user new ticket by agent (on by default)
Emails a user to inform them when an agent has created a ticket on their behalf. Uses the New Ticket by Agent template by default. You can customize the name and account used to send the email.
New reply:
Assign self when replying by email (on by default)
When an agent replies to a ticket via email and the ticket is unassigned, assign the ticket to that agent. Note the action used to achieve this:
In the Set Assigned Agent action, Current Agent means the agent who triggered the event - in this case by replying to the ticket.
Send agent notifications (on by default)
Sends out ticket reply email notifications for agents (based on their notification preferences). The equivalent of the New Ticket “Send agent notifications” trigger, but for replies.
Send auto-reply confirmation to user (off by default)
Sends out an auto-response acknowledging that the user’s reply has been received, using the New Ticket Auto-Response template.
You can customize the name and account used to send the email.
Send user new reply from agent (on by default)
Sends the email with an agent reply to a ticket.
Ticket update:
Send agent notifications (on by default)
Sends the ticket updated email notifications for agents (depending on their notification preferences).
Custom triggers
To customize trigger behavior, you can either modify the settings of the built-in and default triggers, or create your own new triggers.
Don’t edit the built-in/default triggers until you understand what they do. They carry out the important routine functions of the helpdesk, like emailing users agent messages.
When you set up a custom trigger, don’t forget to edit or disable any simple/default triggers which do the same thing.
For example, suppose you have just added a custom trigger to send a special ticket reply notification message to users in the VIP usergroup. If you don’t change the criteria for the default Send user new reply from agent trigger, the VIP users will get two auto-reply emails for each new ticket: one from the custom trigger, and one from the default trigger. To prevent this you would modify the default trigger so it doesn’t run for VIP users.
To create a new trigger, go to Tickets > Triggers then either New Ticket, New Reply or Ticket Update, depending on the type of trigger you want to make.
Specify a Title for the trigger that describes what it does.
You can further refine when a trigger runs using the Event section.
Set criteria which a ticket must meet before the trigger runs. These can be properties of the email, ticket, attachments, user, user’s organization or the current time. You can also check trigger control criteria.
Set the actions which the trigger will run. Actions can be used to notify agents and users, or change the state of a ticket, or even trigger an API call to a web-based service.
See the Actions guide section for full details of the available actions.
Please log in or register to submit a comment.