This section contains some examples of how to implement common requirements using triggers.

You can use these as the basis for your own custom triggers.

If you’re struggling to work out how to implement a particular automation, it’s also worth searching the Deskpro Knowledgebase, as we regularly add examples based on customer requests.

Assign out-of-hours tickets to a special team

Suppose you want to treat incoming tickets differently outside working hours. For example, assigning them to a night shift team who you know will be checking their email.

This is easy to accomplish with triggers:

Note that the working hours here are taken from the Default Working Hours in Tickets > Settings - but you could specify custom hours just for this trigger.

You’d probably want to send out-of-hours replies from users to the same team:

Ignore bounce messages

Suppose one of your ticket email accounts is used as the reply address when you send out your company newsletter. Some of the email addresses the newsletter is sent to are wrong or out of date - as a result, incoming notifications about ‘bounced’ emails are turned into tickets.

You can use the Email bounced criteria to match bounce messages, label them and mark them as ‘Spam’. This means they will be sent to the Spam filter in the agent interface, and periodically deleted (based on your  Ticket purging settings).

Tickets from organization managers are more urgent

If your agents are using the CRM app to record which users are managers of their organizations, you could use this information to increase the urgency of managers’ tickets:

Email users when their ticket is assigned

Suppose you wanted to send an email to the user when their ticket is assigned to an agent, reassuring them that their issue is being dealt with by a named person instead of sitting around in your inbox unread.

Here’s how you could implement this:

1. Create a new trigger, and set the event to be When a property on a ticket is changed/By an agent.

2. You probably don’t want the user to get a notification if their ticket was assigned and replied to at the same time, so deselect Also run when properties have changed during a reply.

3. Add the Criteria: Agent / changed from/ Unassigned.

4. Add the Action: Send User Email > Create new template. An editor opens where you define the email template.

   Here’s an example template:

   Subject:

RE: {{ticket.subject}}
 copy

Body:

   {{ phrase('user.emails.greeting') }} <br /><br />
   Your ticket has been assigned to {{ticket.agent.display_name}}. <br /><br />
   {{ phrase('user.emails.ticket_access_ticket_online') }}
   <a href="{{ ticket.link }}">{{ ticket.link }}</a>
 copy

1. Save the template and trigger. Make the trigger active with the toggle control next to its name.

Note that this trigger doesn’t run when the assigned agent changes, only when the ticket moves from unassigned to assigned. So in most cases, the user would only get the custom email once, but the trigger will also run if the ticket is moved back to unassigned, then assigned to an agent again.

You could refine the trigger so that it only runs the first time the ticket is assigned. One way to implement this would be by using a custom field:

1. Create a toggle field “Has been assigned”, make it agent-only and have it unchecked by default.

2. Add an action to the custom trigger that sets the field as checked when the trigger runs.

3. Add to the criteria of the trigger a check that ‘Has been assigned’ is false. The second time that the ticket is assigned, the trigger won’t run.

Send a different auto-reply to new users

Suppose your sales team wants you to customize the email auto-response when tickets are submitted to the Sales department. They want to send existing users the normal response, but they want new users to get a more elaborate welcome email explaining your product range.

We’ll assume you start out with your sales@ account linked to the Sales department with simple new ticket triggers, configured to send the the default auto-response.

This Email Account Trigger sets tickets sent via the sales@ account to the Sales department, then sends the auto-response.

This Department Trigger sets tickets submitted via the web where the user has selected the Sales department to the sales@ email account, then sends the auto-response.

The simple triggers can’t do what the sales team wants, because their criteria are fixed, so there’s no way to specify that you only want to do something to new users.

Instead, you would create a new trigger:

This trigger is checked when a user or agent submits a ticket via email or web. (We’ll assume that you don’t want to send acknowledgements for tickets created using the API).

The criteria you would use are:

That means the new trigger will only run its actions when the department is Sales, and the user is new. We’re going to rely on the Email Account Trigger to set the department to Sales. Make sure the new trigger is below the simple triggers.

The action you want to run is sending a custom email. You would create a custom email template (see the chapter on  Editing Templates for details), then run it like this:

You don’t want users receiving more than one auto-response email when they submit a new ticket. So you would disable the Send User Email action for the simple triggers:

You also want users who don’t receive the custom email to receive the default auto-response email. Since the simple triggers aren’t sending that any more, another new trigger is needed to do the job.

The simplest way to avoid a user getting both the emails is to put in a check to see if the custom email has already been sent, and make sure the default auto-response trigger is below the one that sends the custom response.

Here’s the completed triggers in the right order: