This article describes the different conditions and actions you can use when creating triggers. For information on creating new triggers, seeCreating triggers for automatic ticket updates and notifications.
This article contains the following sections:
Building trigger condition statements
条件语句的条件,operators, and condition values (these vary depending on the condition selected). Condition statements are essentially ‘if’ statements that return all tickets that meet the specified criteria.
For condition statements such as Ticket: Status, Ticket: Group, and Ticket: Assignee, the trigger will fire whenever the condition ischanged. Changed refers to any update made to the value, even if the value previously did not exist. For example the Ticket: Group trigger condition will fire even if a ticket is created and a group is assigned to it for the first time.
Condition | Description |
---|---|
Object | |
Ticket: Agent replies (Not available on Team plans) |
The number of public agent replies to a comment from another customer or agent within Support tickets. |
Ticket: Assignee | The assignee values are:
Additional value for views:
|
Ticket: Assignee stations (Not available on Team plans) |
The number of different agents to which a ticket has been assigned. |
Ticket: Attachment | This condition checks whether or not the ticket update has any attachments. Both appended and inline attachments are included, with the exception of inline attachments that are added to the ticket using a macro. |
Ticket: Brand (Not available on Team plans) |
Checks whether a ticket is associated with the specified brand. |
Ticket: CC | This condition checks whether or not the ticket has any CCs on it at the time the trigger runs. It does not check for followers or @mentions. |
Ticket: Channel | The ticket channel is where and how the ticket was created. The contents of this list will differ depending on the channels you have active, and any integrations you are using. For more information about the ticket channels you can configure, seeAbout Zendesk channelsandUnderstanding ticket channels in Explore. |
Ticket: Channel name | The name of the messaging channel through which the ticket was created. All active social, web, and mobile messaging channels appear in the list. |
Ticket: Comment | This condition returns the type of comment contained in ticket updates. Publicis a comment that everyone can see. Privateis a comment that only members of the support staff can see. Present (public or private)is used to indicate if the update contains a new comment. Present, and requester can see the commentis used to indicate that the update contains a comment and that it is visible to the requester. This includes private comments, if the requester has permission to view them. |
Ticket: Comment text | This condition checks for the presence of single words and strings of words in the body of a new comment when a ticket is updated. For newly-created tickets, the first comment in the ticket is checked. A previous comment in a ticket is never used to evaluate this condition.
The following content is also checked under certain circumstances:
This condition is not case sensitive. You can use any of the following operators:
|
Ticket: Due date | Checks whether a due date is or isn't present for the ticket. |
Ticket:Custom fields | Custom fields support a subset of operators that vary by custom field type. For all custom field types, you can check to see whether a value is present or not. Additionally,
All ticket lookup relationship fields can be selected under Lookup relationships. All other types of custom fields on a ticket are available under Tickets. |
Ticket: Form (Enterprise plans only) |
Your ticket forms are available as conditions. SelectTicket: Form,n select a specific form. |
Ticket: Group | The group values are:
Additional value for views:
|
Ticket: Group stations (Not available on Team plans) |
The number of different groups to which a ticket has been assigned. |
Ticket: Integration account | This condition checks the integration account that the ticket came from, such as a specific Facebook page, Twitter handle, or other channel integration account, like Google Play. Select one of your configured integration accounts from the drop-down menu.
Note:If there are multiple accounts defined for the same channel type (for example, WhatsApp), tickets can be routed only by channel type, not by a specific integration account. |
Ticket: Intent | An AI prediction of what the ticket is about. To see the possible values, you cango to theTaxonomytabof the Intent settings page. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Intent confidence | How likely it is that the intent prediction is correct. Values areHigh,Medium, andLow. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Language | An AI prediction of what language the ticket is written in. To see the possible values, you cango to theTaxonomytabof the Language settings page. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Language confidence | How likely it is that the language prediction is correct. Values areHigh,Medium, andLow. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Number of incidents | This condition takes an action when the number of incidents on a problem ticket hits a threshold. |
Ticket: On a holiday? (Not available on Team plans) |
This is set to yes during the full day of the holiday, not just during your normal business hours that day. If you have multiple schedules (Enterprise plans only), this condition respects the list of holidays set in the schedule applied to the ticket. |
Ticket: Priority | There are four values for priority:Low,Normal,High, andUrgent. As with status, you can use the field operators to select tickets that span different priority settings. For example, this statement returns all tickets that are not urgent: Priority is less than Urgent |
Ticket: Privacy | This condition lets you test if a ticket has public comments or not. You can select either:
|
Ticket: Received at | This condition checks the email address from which the ticket was received and the email address from which the ticket was originally received. These values are often, but not always, the same. The ticket can be received from a Zendesk email domain such as sales@mondocam.zendesk.com, or from an external email domain such as support@acmejetengines.com. The external email domain must be set up as described inForwarding incoming email to Zendesk Supportor the condition won't work. This condition will work only if the support email address is a valid user address. This condition could be met by an email address in the CC field if it's associated with a user account. Email addresses that aren't associated with a user account (such as Google Groups, aliases, and distribution groups) can't satisfy this condition when in the CC field. Note that this condition doesn't check the channel from which the ticket originated and can be true for tickets that weren't received through email. For example, when using theSelect an Address appyou can specify a recipient email address and therefore meet this condition even though the ticket was created in the agent interface. |
Ticket Reopens (Not available on Team plans) |
The number of times a ticket's status changed from Solved to Open or Pending. |
Ticket: Satisfaction (Not available on Team plans) |
This condition returns the following customer satisfaction rating values:
|
Ticket: Schedule (Enterprise plans only) |
如果你有设置多个时间表,这是schedule applied to the ticket. The available values are the names of your schedules. |
Ticket: Sentiment | An AI prediction of how the customer feels about their request. Values areVery Positive,Positive,Neutral,Negative, andVery Negative. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Sentiment confidence | How likely it is that the sentiment prediction is correct. Values areHigh,Medium, andLow. This condition is available as part ofintelligent triage. Does not work with theTicket|Is|Createdcondition. SeeWhy didn’t my intelligent triage trigger run during ticket creation? |
Ticket: Side conversation (Not available on Team plans) |
You can create trigger conditions for side conversations so that assignees know when a side conversation is created, closed, replied to, and reopened. Without them, the agent assigned to the ticket (who, ideally, is also the creator of the side conversation) may have a hard time knowing what’s going on with a particular issue.
You can use these trigger condition statements with side conversations:
|
Ticket: Status category |
Note:If you’veactivated custom ticket statuses, system ticket statues and any ticket statuses you create are grouped into status categories. Each status category has a default ticket status. SeeManaging ticket statuses. The status category values are: Newis the initial status category of a newly created ticket (not assigned to an agent). TheOpenstatus category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. ThePendingstatus category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. TheOn-holdstatus category contains ticket statuses used to indicate that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status category is optional and must be added to your Zendesk (seeAdding on-hold ticket status to your Zendesk).TheSolvedstatus category contains ticket statuses that indicate that the customer’s issue has been resolved. TheClosedstatus category contains the Closed system ticket status that indicates that the ticket has been locked and cannot be reopened or updated. When selecting a status category, you can use the field operatorsLess ThanandGreater Thanto specify a range of tickets based on their status category.Newis the lowest value, with values increasing until you get toClosedstatus category. For example, a condition statement that returns tickets only in the New, Open, and Pending caetegories looks like this: Status category is less than Solved. |
Ticket: Status |
Note:If you’veactivated custom ticket statuses, existing system ticket statuses become status categories. If you have existing conditions that use Status, they’re updated to the corresponding Status category. The system ticket status values are: Newis the initial status of a newly created ticket (not assigned to an agent). Openmeans that the ticket has been assigned to an agent. Pendingis used to indicate that the requester has been asked for information and the ticket is therefore on hold until that information has been received. On-holdmeans that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status is optional and must be added to your Zendesk (seeAdding on-hold ticket status to your Zendesk). Solvedindicates that the customer’s issue has been resolved. Tickets remain solved until they are closed. Closedmeans that the ticket has been locked and cannot be reopened or updated. When selecting a status, you can use the field operatorsLess ThanandGreater Thanto specify a range of tickets based on their status.Newis the lowest value, with values increasing until you get toClosedstatus. For example, a condition statement that returns only New, Open, and Pending tickets looks like this: Status is less than Solved. |
Ticket: Subject text | Using this condition you can check for the presence of single words and strings of words in the subject line of the ticket. This condition is not case sensitive. You can use any of the following operators:
This condition is not available if the Subject field has beendeactivated. |
Ticket: Tags | You use this condition to determine if tickets contain a specific tag or tags. You can include or exclude tags in the condition statement by using the operatorsContains at least one of the followingorContains none of the following. More than one tag can be added. Press Enter between each tag you add. |
Ticket: Is | Created or Updated. Created will fire only when a new ticket is created . Updated will fire only when an existing ticket is modified and submitted. For more information, seeTriggers: The importance of the 'Ticket is' condition. |
Ticket: Ticket status | If you’veactivated custom ticket statuses, you can select system ticket statuses and new ticket statuses you created as conditions. When selecting a ticket status, you can use the field operatorsContains at least one of the followingandContains none of the followingand specify multiple ticket statuses. For example, a condition statement that returns tickets with either a specific new or system ticket status may look like this: Ticket status Contains at least one of the following: Open, Dev assigned, Escalated. |
Ticket: Type | The ticket type values are: Question Incidentis used to indicate that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket. Problemis a support issue that needs to be resolved. Taskis used by the support agents to track various tasks. |
Ticket: Update via | This condition indicates from where the ticket was updated and can be any of the same sources as the ticket channel condition (above). Autoreply events can't be reliably identified by this condition. Bulk updates to tickets from the Support interface are recorded as updated via a Web Services (API) channel. |
Ticket: Within business hours? (Not available on Team plans) |
Yes or No. This condition is available if an administrator has set business hours. If you are on an Enterprise plan and have multiple schedules, the "within business hours" conditions are based on the schedule that is applied to the ticket (seeApplying your schedules to tickets). |
Ticket: Within (schedule) (Enterprise plans only) |
If you have set up multiple schedules, this activates you to compare the ticket update time toanyschedule, not just the schedule applied to the ticket. The available values are the names of your schedules. |
Lookup relationships | |
Custom object:Custom object(record) | For custom objects related to tickets, the custom object's records are available as conditions. |
Custom object:Custom field | For custom objects related to tickets, the custom object's fields are available as conditions. |
Organization: Organization (record) | The organization values are:
|
Organization:Custom fields | Custom organization fields are available as conditions. If the trigger includes this condition, but the ticket isn't associated with an organization, the trigger does not fire. |
Requester: Requester (record) | Checks theRequesterfield on the ticket. The requester values are:
Additional value for views:
|
Requester:Custom fields | Custom user fields are available as conditions. |
Requester: Is verified by Twitter | This condition is used to verify that the requester is a verified Twitter account. |
Requester: Number of Twitter followers | This is the number of the requester’s Twitter followers. |
Requester: Number of tweets | This is the total number of the requester’s tweets. |
Requester: Language | Returns the language preference of the person who submitted the request. |
Requester: Role | The role of the ticket requester. The role type can be agent, admin, or end-user. Additionally, if you're using light agents, the light agent role type is available. |
Requester: Time zone | The time zone of the ticket requester. |
Ticket:Lookup relationship fields | Ticket lookup relationship fields are available as conditions. |
Ticket details | |
Current user | You can select any of the following for the type of user that last updated the ticket:
If a ticket is created by an internal system event such asvoicemail,Current usercondition is not applied. When a voicemail ticket is created, the first comment on the ticket is added by Support as a private comment and includes the voicemail recording, but Support doesn't interpret the comment as being from a user. TheCurrent usercondition is not supported when the ticket is from a messaging channel. |
Ticket sharing: Sent to | Checks whether a ticket was shared to another Zendesk via a specific ticket sharing agreement. |
Ticket sharing: Received from | Checks whether a ticket was shared from another Zendesk via a specific ticket sharing agreement. |
Building trigger action statements
Action | Description |
---|---|
Object | |
Ticket: Add CC | 添加一个代理或当前用户复制ticket update. This action is available when you activate CCs on tickets. |
Ticket: Add follower | Add an agent or the current user as a follower on the ticket update. This action is available when you activateCCs and Followerson tickets. Also, when you activate this feature, the Ticket: Add follower action replaces the Ticket: Add CC action. |
Ticket: Add skills | The skills you want to add to a ticket. Any existing skills on the ticket are unaffected. This action is available when omnichannel routing is enabled and you'vecreated at least one skill. |
Ticket: Add tags | The tags you want to add to the existing list of tags (if any). Tags must be separated with spaces. |
Ticket: Assignee | You can set the assignee to any of the following:
Additional value for triggers and macros:
|
Ticket: Autoreply (Advanced AIadd-on only) |
Add a public comment to the ticket to attempt to directly answer the customer’s request. For more information about using this action, seeAdding a public comment to a ticket using a trigger. |
Ticket: Brand (Not available on Team plans) |
Add a brand to the ticket. |
Ticket: Form (Enterprise plans only) |
Your ticket forms are available as actions. Select a specific form. |
Ticket:Custom fields | Checkbox, drop-down, text, number, and date custom fields are available as actions. |
Ticket: Group | You can set groups to any of the following:
Additional value for macros:
|
Ticket: Internal note (Advanced AIadd-on only) |
Add an internal note to the ticket. For more information about using this action, seeAdding an internal note to a ticket using a trigger. |
Ticket: Priority | The priority can be set toLow,Normal,HighorUrgent |
Ticket: Remove tags | The tags that you want removed from the existing list of tags contained in the ticket (if any). Tags must be separated with spaces. |
Ticket: Satisfaction | You can set this action to:offered to requester. This indicates that the survey request has been sent to the ticket requester. |
Ticket: Remove skills | The skills you want to remove from the ticket. This action is available when omnichannel routing is enabled and you'vecreated at least one skill. |
Ticket: Set schedule (Enterprise plans only) |
Your schedules are available as actions. SelectTicket: Set schedule,n select a specific schedule. When you set up multiple schedules, you must create triggers to apply your schedules to tickets. |
Ticket: Set skills | The skills you want to insert into the ticket. The set skills action deletes all skills currently applied to the ticket and replaces them. This action is available when omnichannel routing is enabled and you'vecreated at least one skill. |
Ticket: Set tags | The tags you want to insert into the ticket. The set tag action deletes all tags currently applied to the ticket, or associated with any ticket fields, and replaces them. Tags must be separated with spaces. |
Ticket: Share ticket with (Zendesk Suite Growth and above or Support Professional and above only) |
Share the ticket with the specified account. Requires that a ticket sharing agreement be in place. See SeeSharing tickets with other Support accountsandUsing business rules to share tickets. |
Ticket: Status category |
Note:If you’veactivated custom ticket statuses, system ticket statues and any ticket statuses you create are grouped into status categories. Each status category has a default ticket status. SeeManaging ticket statuses. When you use a status category as an action, the ticket status is set to the category's default ticket status. The status category values are: Newis the initial status category of a newly created ticket (not assigned to an agent). TheOpenstatus category is for grouping ticket statuses that indicate when tickets are ready to be worked on by your support team. ThePendingstatus category is for grouping ticket statuses that are used to indicate that the support team is waiting for the requester to reply. TheOn-holdstatus category contains ticket statuses used to indicate that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. This status category is optional and must be added to your Zendesk (seeAdding on-hold ticket status to your Zendesk).TheSolvedstatus category contains ticket statuses that indicate that the customer’s issue has been resolved. TheClosedstatus category contains the Closed system ticket status that indicates that the ticket has been locked and cannot be reopened or updated. |
Ticket: Status |
Note:If you’veactivated custom ticket statuses, existing system ticket statuses become status categories. If you have existing actions that use Status, they’re updated to the default status of the corresponding Status category. The system ticket status values can be set to the following: Newis the initial status of a newly created ticket (not assigned to an agent). Openmeans that the ticket has been assigned to an agent. Pendingis used to indicate that the requester has been asked for information and the ticket is therefore on hold until that information has been received. On-holdmeans that the support request is awaiting a resolution from a third party—someone who is not a member of your support staff and does not have an agent account in your Zendesk. Solvedindicates that the customer’s issue has been resolved. The ticket is solved even if required ticket fields are still blank. SeeRequired fields and automations. Tickets remain solved until they are closed. When tickets are closed is based on business rules you define for this step in the workflow, using automations. Closedmeans that the ticket has been locked and cannot be reopened or updated. |
Ticket: Ticket status | If you’veactivated custom ticket statuses, you can specify actions that set the ticket status to a new or system status. |
Ticket: Type | The type can be set to the following: Question Incidentindicates that there is more than one occurrence of the same problem. When this occurs, one ticket is set to Problem and the other tickets that are reporting the same problem are set to Incident and linked to the problem ticket. Problemis a support issue that needs to be resolved. Taskis used by the support agents to track various tasks. |
Lookup relationship | |
Custom object:Custom object(record) | Select a custom object record to relate to the ticket. |
Organization:Custom fields | Custom organization fields are available as actions. If the trigger includes this action, but the ticket isn't associated with an organization, the trigger does not fire. |
Requester: Language | Set the requester's language to one of your supported languages. |
Requester:Custom fields | Custom user fields are available as actions. |
Ticket:Lookup relationship fields | Ticket lookup relationship fields are available as actions. |
Other | |
Notify by: Active webhook | Set the active webhook to notify. For more information about using webhooks, seeCreating a webhook. If you select a different notification destination when editing a trigger, the body text will reset. |
Notify by: Autoreply with articles | Sends an automated email response to the customer's request. The email contains help center article suggestions to help the customer resolve their issue. For more information about email autoreplies, seeConfiguring email autoreplies to deflect requests. |
Notify by: External target | Set the external target to notify. For more information about using targets, seeNotifying external targets. If you select a different notification destination when editing a trigger, the body text will reset. |
Notify by: Group email | You can set email group to any of the following:
If you select a different notification destination when editing a trigger, the body text will reset. |
Notify by: Group text | If you are using Zendesk Text, you can configure a text to be sent to a group of users when the trigger conditions are met (seeUsing Text notifications with triggers: Recipes and tips). |
Notify by: Request messaging rating | Sends an automated satisfaction survey at the end of the conversation. SeeAbout CSAT ratings in messaging. |
Notify by: Tweet | Respond to the Twitter requester with a Tweet. An @mention, and shortened ticket URL are added to the message so make sure to stay within the maximum Tweet length. |
Notify by: User email | You can set the email user to any of the following:
Additional values for triggers and automations:
The email notification is sent only if the update includes a public comment. If the update has a private comment or no comment, the trigger or automation can still fire other actions, but it won't send the notification. There's a known limitation for using theEmail user + (requester and CCs)action and theTicket + is + Updatedconditions in triggers. When used together, Support suppresses emails to a user if the ticket update is from that same user. This is expected behavior to eliminate redundant emails. For more information about suppression, seeUnderstanding suppression of CCs email notifications. Adding the email user action allows you to enter the email subject and body text. Body text can be formatted using HTML or placeholders. SeeUsing placeholdersfor more information on formatting with placeholders. If you select a different notification destination when editing a trigger or automation, the body text will reset. |
Notify by: User text | If you are using Zendesk Text, you can configure a text to be sent to the user when the trigger conditions are met (seeUsing Text notifications with triggers: Recipes and tips). |
Notify by: Zendesk integration | When using the Slack for Zendesk Support integration, you can notify Slack users about Zendesk ticket events. SelectNotify Zendesk integrationandSlack integrationfrom the drop-down lists. |
80 Comments
Is there a way to get the trigger to look for line breaks? For example, we have a feedback option in our app and it just starts a new email with pre-populated information that we need from them. The email reads something like this:
We have a lot of users that hit the feedback button then hit Send without filling anything additional in. I'd love to be able to set a trigger up to catch these "blank" emails and send a reply asking if the user still needs help.
My issue is figuring out how to tell the trigger to look for incomplete emails. If I tell the system that the string must contain "access code: clinic:", will it detect the above example?
Hello Joshua!
Unfortunately trigger conditions can only look for what is present in comment text, not what is missing. So you would only be able to have a trigger find a specific text value in the comment text and you cannot use blank spaces as a value. Using the string "access code: clinic:" will not work because of the line breaks. There isn't a native way to automate finding these gaps.
Cheers!
Thanks,@.... I figured that was the case, but wanted to see if there was any magic I wasn't aware of. As a solution I've requested that we move to using a fillable form with required fields instead of just an email.
I'd like to have a trigger run when a ticket is changed to Solved, and then 3 days later an automation runs to change the status to Closed, at which point I'd like another trigger to run.
What is the difference between do "Status IS Solved" versus "Status CHANGED TO Solved"?
Same question would apply to Closed. Why would I use "changed to" instead of "is", or vice versa?
Thanks!
Hi Steve!
"Changed to" is useful when you want your Trigger to fire only when the status has changed on that specific update. "Status is" can be used even if the status has not changed. For example a comment may be added to the ticket, but nothing else changed. You could test the value of the status using "is" to ensure that the status is still solved.
For your specific case, the Triggers might benefit from using the "changed to" condition but the automation can only use the "is" condition (or "is not" and the "less/greater than").
I hope that helps!
Hi!
我们有一个触发时将通知一个终端用户public reply has been made on their open ticket. This trigger is obnoxious for Social Media responses since it's far more conversational than our email team.
I was hoping to use the "Update via“防止触发激活条件for our Social Media channels but when I test out the functionality it doesn't seem to work as expected. In contrast, when I use the "Channel" condition it will prevent the trigger from activating. That being said, "Channel" does not work in this case since we may have Specialists who will be responding via email in the same Social Media ticket, and we would want those emails to activate the trigger.
I put "Update via is not Twitter DM" but the trigger still activated. When I put"Channel is not Twitter DM" the trigger did not activate and prevented the trigger from activating when an email was sent from the same ticket. From the above definition it seemed like "Update via" should have functioned like"Channel" but only for the individual responses, not for the creation of the ticket.
Am I barking up the wrong tree?
Thanks!
我想创建一个触发器,邮件用户when a ticket has aged 30 days from create date without being closed.
我看不到任何方式所需的老化的电导率ition evaluated in the trigger.
Is there a way to do that?
Hi Jorgen,
For this use-case, you would use an automation rather than than a trigger:
https://support.zendesk.com/hc/en-us/articles/203662236-About-automations-and-how-they-work
Hello@...,
We need to investigate this further.
I will take this into a ticket and you will hear from me shortly.
Hi All,
我如何创建一个触发器,反应吗when a drop down field has changed its value?
I'd like to email people when the dropdown changes from A to B, or B to C etc... Thank you
Hi Viktor –
Currently there's no built-in way to do this. It may be possible to use tags to keep track of the former field value and then use a trigger for each value to check to see if it's changed by comparing the current/new value with the tag, but that could be difficult to maintain if you have a large number of field values.
Can you add your use case to this Product Feedback thread?Feature Request: Add "Changed", etc, trigger test for custom Drop-down ticket fields
There is one thing that I'm not able to find.
I can't find a Condition that would understand if the last reply in the ticket is from an agent or from a customer.
I'm trying to set up an alert that would fire if the customer replies and the agent doesn't reply back for longer than x hours. However, not all Open tickets have the last reply from a customer as our workflow also allows tickets to stay in the Open status after the agent replies.
I'm trying to use Automations for that, but can't find a way to compare agent replies vs customer replies.
HiTomica,
I hear you! I wonder if one of these option in the automations would help? "Hours since requester update" or "Hours since assignee update".
If not, I'm thinking you can get this working more precisely if you add 2 triggers that add/remove tags that you can use in the automation.
You'll now be able to better use the automation "Hours since assignee update" + tag lastupdater_enduser.
Definitely test this out a bit and let us know if it helps!
Heather,
The "Current user" condition was a missing part.
Thank you so much.
Hello everyone,
I'm having some trouble to set-up some conditions for a trigger to send notifications to Slack when a specific agent is mentioned on Zendesk. The agent's Zendesk alias is Ana, so I created some conditions to find private comments with comment text containing Ana. However, this trigger is also firing when words like manager or Canada are used in the comments.
I tried to change the field comment text to "Ana", but then the trigger is not firing when agents mention her (using @Ana). Is there any workaround for this situation?
Hi! Is there a way to write condition statements that run IF FALSE?
E.g. I have a custom user field that is and I want to add a tag to a ticket if that user field is older than 5 days. I am today able to write an automation if that parameter "is within previous" number of days, but not the opposite. Any workaround?
Buenos dias,
Una consulta, que diferencia hay entre la siguiente condicion y sus caracteristicas:
- TEXTO DEL ASUNTO
(Contiene la siguiente cadena)
(contiene una de las siguientes palabras)
La primera que indica cadena me podrían poner un ejemplo porfavor, estoy creando un disparador y tengo que usar esa condicion, gracias.
How would I use triggers for time? Would this be something else?
For example, I want agents to take an action 2 weeks after the last contact. How would I do time based triggers?
Hi ELVT AM.
You need to use Automation for time-based business rules. More information can be found here:About automation and how they work
I would like to create a trigger that prevents a ticket from being updated if a string of text is not omitted. I want to set this up to ensure that the agent does the necessary checks in a specific macro before sending the email to the customer.
If I set a Meet ANY/ALL conditions with Comment Text contains the following strings:%$#*
And if the macro used by the agent contains the string%$#*
Is there a way to prevent the ticket status from being updated/email not being sent out?
I can't seem to figure this out!
Thanks!
Hey Tinesh,
You can't prevent the update but you can reset the status back to open to give the illusion of that behaviour.
Using the conditions above, add the action Status-> Open and whenever the comment with that string is made, the ticket will be set back to Open. If you do this, it's good practice to alert the agent in someway as to why the ticket remained open, since it would be contrary to normal expected behaviour. We've done that through aSlack alert, but you can do it via email or other alternatives as well.
I would also consider adding a condition to your trigger that manages your outbound email notifications. I would think of adding
Commentdoes not contain the following string%$#*
in addition to your other conditions.
That way you can be sure that even if the string is present, no notification will be sent on that ticket update and the status can't be set to solved or any other state than Open.
Hope that helps!
Thanks for jumping in here,@...!
Is there a way to create a trigger that opens up a new ticket form for the user to fill out? We have a registration form and one of the options is to request a token. The token process is totally separate and needs its own ticket for the process to work correctly. So when the user submits the registration request, if they have indicated that they want to order a token, we would like them to be presented with the Token Request form to fill in.
Margaret Boisvert
You can approach this a few ways. If there's nothing the main ticket can't see, you can actually use conditional fields so that when the customer selects "request a token" you surface the fields on the form for them to fill out along the other fields.
Then on your Agent side after the main ticket is created, you can use an app likeSplit N Close(disabling the close feature) to create the 2nd ticket. OR you can put in a macro to create a side conversation ticket (Collaboration Add On needed) and prefill the description with the values in the fields for the request a token fields you've collected. More on thathere.
I'm sure a developer could help you with an API ticket creation also if you have the resource.
Thanks Heather! I actually ended up going that route :)
Hi! Is there any way to fire a trigger depending on the presence of the user's phone?
Unfortunately not as Triggers are ties to ticket updates. Unless the users phone number was present somewhere is the subject or body of the message then you could use a String condition but it would not be able to identify it directly from their profile. You may also be able add a custom field and use Macro's if the field is present but it would not be an automated process.
Thank you!
Hi Jason, thank you for your response :). It would be a nice thing to have this feature in the future.
Hello!
I set up a trigger for our customers to automatically get if a proper tag is applied to the ticket. Unfortunately when the trigger fires there is no history of the trigger in the ticket history. Is there a condition I missed in 'Actions' to ensure the trigger history is shown to our agents when they open the ticket?
Thanks!
Hi Dylan,
You'll want to toggle this from Conversation to Events and you should see it there :D
Pleasesign into leave a comment.