Triggers & Automations - We want your feedback!


  • Pedro Rodrigues
    Community Moderator

    Hey @..., we're always happy Zendesk pays attention to admin needs regarding business rules (or anything, really!). Admins are Zendesk's "unsung ambassadors" and it's great you're asking us how to improve these important core product features!

    To answer your questions:

    • Triggers just because of their nature (immediacy and execute on update; automations are limited as they only execute every hour and up to a max number of tickets).
    • Depends on the type of trigger and how often workflows change, I guess? I've maintained over 1,200 at some point.
    • Depends, but I'd say "Ticket is" (created/updated). On multibrand accounts, "Brand is" is also definitely used.
    • No. 
    • Not really sure, but if I had to guess I'd say "Add tags". 
    • No. 

    Additionally, here's some personal feedback on improvements I'd like to see regarding business rules:

    • Automations page. It's a crucial feature of the product and they're a bit obsolete, to be honest... Autos need an urgent update! Not just the automations page design, but automations also need version control/revision logs like triggers already have (I'd even argue Views and SLA policies should also have version control!)
    • Triggers. Could be revamped and have multiple and/or conditions (see my post from a few years ago)
    • Admins should be able to edit Closed tickets, even if only using business rules (as opposed to manually/in bulk). This is essential for proper data hygiene.
    • Agent Workspace. We should have the ability to detect strings in messages via triggers (just like comments in 'classic'/email tickets), as well as being able to detect which user is messaging in the latest update (e.g. I usually add a tag to tickets in order to know who commented last, the requester or an agent; during a messaging conversation, this isn't possible).
    • Create internal, admin-focused triggers based on system events (new group created, view/trigger/automation/etc deleted/created/etc), with the ability to notify with pop-ups (like Notifications app) or by email. For that to happen, we'd also need more complete and explicit audit log events, a feature that is still somewhat underwhelming (although the latest filtering ability is a time saver).
    • Being able to identify business rules with invalid conditions, this would be a good use case for the admin trigger notifications mentioned in the previous bullet (i.e. as soon as a trigger condition is invalid, me or all admins would be notified).
    • Trigger conditions and actions for suspended tickets
    • Not necessary related to your post, but Skills-based routing should execute after triggers apply to tickets, not before. This is a crucial aspect that has frequently prevented me, as an admin, from recommending the feature entirely.
    • Skipped tickets. Trigger condition for "Ticket is skipped".
    • Change the ticket recipient ('sender address') via triggers or automations  

    Lastly, and looking at the most voted posts in the Community, some of these requests features:

    In general and to sum up, admins are hired and expected to conduct maintenance and clean-up tasks, whether one-off or periodical. Without a solid audit log event scheme and notification feature, we kind of have our hands tied to do a proper job, and have to resort to workarounds for things that (IMHO) should be present in the product already, so that we could focus on what's really important (the customer experience).

    I do realize this comment is more of a Christmas list, and that not all is a priority or even planned on Zendesk's roadmap. Still, thank you for taking the time to review our needs!

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Hi Pedro Rodrigues thank you for all the detailed feedback! These are great opportunities for the various teams at Zendesk to dig into. I'll work to route these to the appropriate PMs.

    In terms of the Triggers & Automations related feedback here...

    • Would you say that tags are being used most frequently because there is something you can't do with the current functionality? 
    • Automations is certainly on our list to tackle. 
    • Any chance you would be willing to share a specific use case of how you would use And/Or conditions? We are currently exploring ways to expand our logic and this will be really helpful. 
    • Triggers on system events is something we are exploring, but related to custom data, so this is a really interesting add. Thank you! 
    • When you think through how you'd want to be notified a business rule is no longer valid, what does that look like? A notification when modifying something that will impact a business rule? Or a banner on your triggers list page that tells you to go look at 'Rule 1'? Or solely the email notification you mentioned? 
    • What is your use case for triggers on suspended tickets? Are you just trying to categorize them, route them, something else? 
    • For skipped tickets as a condition, how will this help your workflow? This is actually a new one too, thanks! 

    I believe those are all the ones that live in my ownership area. Also, if you are up for it, there are additional questions in the linked form for more detailed feedback. 

  • Dan R.
    Community Moderator
    Zendesk Luminary

    Hey Bailey Whitaker-Lea, thanks for posting this! I'm excited to hear what the team is cooking up and I'd be happy to volunteer for a feedback/investigation call if needed!

    To answer your questions:

    1. Triggers, by far. Most workflows require the system to be responsive to input, and as triggers execute immediately, they’re naturally more widely used. As Pedro Rodrigues said, Automations are limited to hourly execution and have a maximum execution limit. We also don’t know when in the hour they’ll run, which makes them harder to predict.
    2. Depends on volume and maturity of the workflow they power. New workflows usually get daily tweaks from user feedback and data review, mature flows or ‘core’ flows that affect all tickets seldom get adjusted.
    3. Usually Ticket is Updated, Tags contain(or do not contain) alongside Ticket Form (to ensure a workflow only applies to a certain type of ticket)
    4. Yes. It would be great to define a bundle of conditions that we could use in a repeatable manner (ex form is X, group is Y, and zodiac sign is Taurus) into a single selector for easy reuse. I usually just clone out a related trigger and tweak from there. It would make bulk updating triggers using same conditions MUCH faster. (This would also be insanely useful in Views).
    5. Send event to webhook (we push data to external services fairly often, mostly to Slack)
    6. Add tags
    7. Yes, often for webhook actions. It’s technically possible to do if/else conditionality in the webhook body using Liquid, but the mere existence of Liquid is proof there is a cosmic deity out there that thrives on our suffering. Even if you get it to work, it’s a huge pain to debug if anything goes awry, so it’s usually simpler and safer to avoid it, and just create duplicate triggers with one minor condition added for filtering.  If proper if/else logic was possible to implement in a trigger, that would make things so much better!
      (example: We CSAT our customers on a 1-5 scale, with 1-2 considered 'bad' , 3 as 'neutral' and 4-5 as 'good'. I need to send alerts to slack for those surveys when 

    Like Pedro, I have a wishlist of Triggers and Automation improvements that would make admin life so much easier.

    • I'm sure you know this one already, but the Automations UI needs to be modernized, please. Even without features like versioning likes Triggers have, just the ability to search fields instead of a monster list every time would be a huge time and sanity saver. IMO, it's the second most painful UI in the entire platform today (dubious first place goes to Dynamic Content).
    • Triggers and Automations have a disparity between being able to use a field as a condition and being able to use it as an action. This gave rise to the workflow of having Zendesk send itself an API call to set certain field types which can lead to other issues (ex: changing ticket requester, changing ticket received at email, set certain field types back to a null or empty state)

    The types of operations available for certain field types needs to improve.

    • For example, I have a numeric field type, we need to be able to test for is, is not, greater than and less than. Right now I have is, is not, present, not present. 
    • Text fields need to be able to search for a value more flexibily (is, is not, contains, does not contain, is changed). Today, we only the lovely choices of ‘Present, Not Present’.
    • Date fields need to be able to understand the concept of ‘today’ as well in conditions. (Ex: date is before today).
    • Every field type should also be possible to set back to an empty value (for an example, try setting a date field back to an empty value via a trigger action. You end up needing the aforementioned API workaround.
    • Being able to have Zendesk surface or filter any rules that have invalid conditions (deleted fields, values etc.) would be really helpful, especially in multi-admin environments.

    Again, super excited to hear that Zendesk is looking to improve this part of the product. Let me know if I can help further!

  • Ian Marston

    I came across this great tool from a 3rd party which allows you to run a health check on most of the config including triggers and automations
    I am surprised a similar tool isn't already a part of the standard Zendesk offering, could you please review and consider this for future development?
    This app enables Zendesk administrators to quickly detect and fix broken references in Triggers, Automations, Views, Macros and Service Level Agreements (SLAs).

    • Audit Triggers, Automations, Views, Macros and Service Level Agreements (SLAs) for broken references
    • View a quick summary to show what needs your attention the most
    • View a detailed line-by-line breakdown of each issue
    • Navigate directly to the problem with a single click
    • Filter results quickly isolate areas of interest
    • Export results to easily get input from other stakeholders
  • Harper Dane
    Zendesk Luminary

    Do you use triggers or automations more? Why? 

    Triggers, as others have said, because of the immediacy. I would move several existing triggers over to automations if I could have a greater level of control over when those automations execute — for example, if I could put a 10- to 15-minute delay on our "We received your request" acknowledgment email (which, in our case, includes AB suggestions), I would do that. I feel it may increase open rates instead of just being dismissed out of hand as "yet another bot-generated email." One hour seems a bit too long, and that's currently the minimum amount of time I can wait before executing an automation.


    How often do you make changes to your triggers? 

    Weekly, and depending on seasonality, sometimes daily.


    What is your most used condition in triggers?  

    Ticket creation, by a wide margin. We use a lot of tag-based logic as well, though.


    Do you find yourself repeating this condition in multiple triggers due to product limitations? 

    Yes, we have many triggers with certain sets of conditions where the actions need to be slightly different on each, or vice-versa — tickets with many different sets of conditions, all with identical action sets.


    What is your most used trigger action? 

    Setting the Form, and some of our custom fields. The form and one of our custom fields dictates everything about a ticket from who it gets routed to what Priority it's assigned, so we have to have a rule for every little thing that comes in so that it ends up with Form and (our custom version, not native) Ticket Type.

    We also have a lot of "auto-solve" triggers, for tickets that we need to keep searchable for agents in our instance, but with no immediate action to be taken. 


    Do you find yourself repeating this action in multiple triggers due to product limitations? 


    I agree with a lot of other users' wishes above, including modernizing the Automations UI and the fields it can take action on. This is my personal wishlist for Trigger & Automation improvements:

    1. Trigger & Automation Actions upon SKILL.

      We really really REALLY want to use Skills-Based Routing, but can't in current state because there's no way to automate the removal of Skills for certain special exception cases.

      Skills work well only if 100% of tickets meeting certain conditions should have a certain Skill. If 5% of your tickets are exceptions that you want to write special Trigger rules for to swap out the Skills on that ticket… you can't.

      We need to be able to reset ticket Skills when agents reassign or re-classify their tickets (by changing the Form, custom fields, etc) — must-have is by using Macros and Triggers, but potentially using Automations, too.

    2. ELIF logic for Trigger Conditions.
      For example, after the current section that says "Meets ALL," include an option to add an additional "Meets ALL" section apart from the first one.

      This would really help us clean up our trigger list and eliminate redundancies, like our — no lie— 55! "Auto-Solve" triggers, which all have specific "Meets ALL" conditions and "meets ANY" simply won't cut it. Nearly all of these "auto-solve" triggers have identical actions.

    3. Flag conflicts in the Trigger list with a warning.
      This one is a pretty wild dream, but it would be an incredible improvement.

      For example, if you have a rule at position 5 that adds a certain tag, and a rule at position 3 that checks for that same tag in its conditions, that's a potential conflict in your trigger firing order. Flagging those conflicts so that admins can easily identify and fix potential conflicts at a glance would be really great.

      I'm currently tracking this using a Google Sheet of manually entered Conditions and Actions. Yes, it looks just as ugly as it sounds!


  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Thanks for the great feedback Dan R. and Harper Dane !

    Dan - your feedback validates quite a few improvements we are looking at. We are also considering expanding the data triggers can interact with, outside of the ticket. For Automations, I'm curious, is there a time interval you absolutely need? 15 minutes? Once at a specific date/time? The survey linked has some more detailed questions around use cases for the data being used in triggers as well as some of the enhancements you mentioned. It would be really helpful to have your input there too! 

    Harper - Interesting feedback around Skills! I know the Skills team has been working on ways to integrate with triggers, so I will make sure this use case gets routed to them. I absolutely hear you on the logic! We are actively working on enhancements in this area. Also, your last point would be a great tool for Admins. I'll add this to our feedback tool as we consider ways to help Admins identify issues with their workflows. I'd love to get your responses to the survey as well if you have the time! 

    Thanks all! 

  • Dan R.
    Community Moderator
    Zendesk Luminary


    Thanks for replying, glad the feedback is helpful! I've filled out the survey!
    As for automations, being able to do 15 minute increments would be really helpful. I don't think I'd realistically need shorter than that. Being able to have an automation only ever run once would be helpful, often I'll set them up to try to fix a data issue in bulk, but don't want it running forever.

    Being able to see the timestamp of the last time the automation ran for the last X runs and a count of number of tickets affected would be really great too. 

  • Harper Dane
    Zendesk Luminary

    Agree with Dan R on all of the above.

    Increments as low as 15 minutes for automations would be a game-changer.

    Seeing a log of tickets that a given automation has run on would also be extremely helpful (the same tool that we have for triggers at [instance][triggerID]/tickets, but for automations).

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Dan R. You're so fast! 

    I'll take a look at your survey responses and reach out via email as we kick off more in depth interviews. 

    Thank you again for the feedback, super helpful! 

  • Dan R.
    Community Moderator
    Zendesk Luminary


    Triggers and Automations are near and dear to my heart so I'm happy to prioritize writing feedback that will help make them better! Also, Harper Dane I didn't know that feature existed, that's incredibly helpful! I wish that would be accessible easily from a trigger! 

  • Harper Dane
    Zendesk Luminary

    Dan R. I just tested that firing log link and it turns out it actually works for automations as well, which I never realized before. Just paste your Automation ID number in, instead of the Trigger ID.

    That said, this feature is hidden, not terribly user-friendly, and ZD Support has previously indicated to me that this firing lookup tool is deprecated and could go away at any time. That's all really a shame, as I use it on a near-daily basis and I'm certain I'm not the only one who finds it extremely valuable (or would... if people knew about it).

  • Anne-Flore Caire


    I would like to add to the feedback already given, with some repetitions (sorry)

    1-We mainly use triggers because we need actions after an input/action rather than over time

    2-We modify our triggers regularly, when a new use-case appears and we need to set up a new workflow. Or to improve triggers that were built at launch and were not optimised (as the years go by, our admin skills improve)

    3-The most used conditions: "received at", "current user", "role" (requester) and "tags"

    4-Yes, because it has already been written, we cannot create multiple groups of conditions and operators. We do it in other software (where we can sometimes switch to an advanced mode, to write complex conditions (as we already do in Explore for custom measures and attributes)).

    5-The most used action: qualifying ticket fields and sending notifications

    6-No, it doesn't seem to me


    The conditions are missing usable data, especially in what I had noted to myself:

    - Trigger:

    o Submitter: we currently have a problem with setting up actions, especially when an agent or light agent transfers a customer's request to us, because this creates a ticket with the customer as the requester and the agent appears in a second comment just after, but it is impossible to create the conditions for action. If we had the Sumitter, we could do something

    o We have the same problem with the impossibility of creating criteria to have a defined action on transferred calls. But here I don't know what data exists.

    o On the domains or organisations: because we have a problem with the creation of an organisation with certain generic domains and it is impossible to create an alert notification for the follow-up

    o Recipient (Ticket email address) : As said by others we had to set up an API call to get around this very big problem when a ticket goes from one department to another and the exchange has to continue via another email address (so that the next requests go directly to the right team)

    - Automatism :

    o The condition for searching a text on a ticket comment does not exist (can only search on the first comment "Description")

    And for the Administration part, already said but being able to identify business rules with invalid conditions is very important. Some invalid conditions may be due to users who have left, I will see more at least a tab or a filter that allows you to display the rules that contain errors.


    Thank you for asking our opinion.


  • Anne-Flore Caire

    To complete my feedback, another lack in the triggers in particular, are the conditions especially on phone calls. I don't know about the other channels other than email, but for telephony for example, we don't have specific triggers, so we have to go and look for text to identify the line called, we don't have triggers for IVR choices either...

  • Lan Margosis


    We use triggers to alert end users of updates to their tickets. It would be fantastic to be able to update our agents about tickets via triggers.

    The problem is that tickets contain the requester's name, which is HIPAA Protected Health Information (PHI). Our agents are not allowed to receive PHI in their emails. When a trigger emails an agent regarding a ticket, the email contains the ticket information including the requester's name. There is no way to remove ticket information from triggered emails at this time, which I confirmed with Zendesk support.

     It would be great if triggers had an option to remove the ticket information altogether. 

  • Wouter Wolff


    Triggers are awesome, however we'd really would be helped within Sell if we can have the trigger automate updating a Deal to Hot when there has been on update on it for x amount of days. Or maybe even better, have a way to update it as 'rotten', to identify rotting deals, due to lack of activity. 


  • Stephen


    Great to see feedback being taken on this topic - see answers below:

    • Do you use triggers or automations more? Why? 
      Triggers - we use them primarily because they run on ticket creation / update, as opposed to being time based.

    • How often do you make changes to your triggers? 
      Once a Trigger is created, we rarely make modifications to them (providing they are working as intended). However, when developing new workflows / temporary workflows, these can updated and maintained frequently.

      At the moment, we are reworking our entire workflow in Zendesk and with that brings many updates to Triggers.

    • What is your most used condition in triggers?  
      Ticket is Created / Updated and checking if a field = value.

    • Do you find yourself repeating this condition in multiple triggers due to product limitations? 
      Yes - very frequently. A lack of conditionality on Triggers means, that Ticket is Created / Updated requests are repeated a lot.

      In addition, due to the lack of field changed or field changed to value conditions for custom fields, I have a bunch of repeat Triggers just checking if a field = value, but does != another value.

      In general, this results in having lots of Triggers to manage.

    • What is your most used trigger action? 
      Setting Forms / Setting Priority / Setting fields and possibly sending notifications via email / Slack.

      I have found more and more we are relying on calling webhooks is something we need to utilise.

    • Do you find yourself repeating this action in multiple triggers due to product limitations? 
      Yes - for the same reasons as the question about Trigger limitations.

    Some other general feedback, I would like to add:

    • Automations UI - this is way behind the rest of Zendesk. Creating Automations is slow and cumbersome compared to the Trigger UI. In addition managing Automations is frustrating.

      The UI feels way out of place compared to most of the other elements of the Admin Centre (Dynamic Content not withstanding).

    • Audit Trail for Automations / Triggers - as an Admin, I would like to have a clear place to see every ticket an Automation / Trigger has run in from the Admin Centre. This is necessary for troubleshooting issues and ensuring workflows have run successfully.

      From this thread, I have learned there is an ancient looking method of seeing where a Trigger has run (which while ugly as sin) is really helpful. Modernising this functionality and bringing it to Automations would be fantastic.

    • Conditional Logic - this is a major missing feature and results in having many duplicated Triggers. The ability to do IF / ELIF / ELSE would make Triggers / Automations far more powerful.

    • Detect changes on Custom Fields - having this as a condition would be excellent. Field changed to / from and Field changed.

      Combined with conditional logic this would improve my overall Admin experience.
    • Add / Remove CCs - being able to cc end-users on tickets via Triggers / Automations would be great.

    • Group assignment on Follow-up Tickets - when a follow-up is opened, the group is empty. Preserving this value from the original ticket would be massively helpful.

    • Ability to use Liquid Markup in Text Fields - Liquid Markup is so useful in Triggers, but there have been times where I want to add a value to a number field ({{ field_name | plus: 2 }}) - this basically isn't possible without using a webhook to update the ticket (something which is not officially supported by Zendesk). Being able to access that value and use Liquid Markup to update it would add so much functionality to these fields.

      String based filters such as appending / formatting would be another example of where I would like to use these values.

    • Triggers on Suspended Tickets - a special category of triggers for suspended tickets would make the experience of managing suspended tickets way better. The Shredder app shows the type of functionality that I would like to see.

    • Parsing / Regex to detect incoming Subjects / Description content - this is a big ask, but would be a nice to have. We have scenarios where customers will contact us via email with a formatted mail - being able to directly pull content from those mails and set fields based on content would be great. For example - Severity = P1, set Severity field to P1 - System Outage.

    • Orchaestration - this is the biggest ask I would have. Being able to wait for a result from a Trigger / Automation operation to complete and follow it with another condition / action would bring Triggers / Automations in line with the best in class business automation tools I have seen.

      In particular, sending a webhook and being able to wait for the response to take some action based on that value would be great. Not having to rely on ZIS and the need for some development skills would be a game changer.

    Other than that (and likely tying into my final point), having the ability to report or see real stats on Trigger / Automation usage would be great - including where a Trigger / Automation failed, webhook failures (and error codes), etc.

    My general feeling is that Triggers / Automations were powerful about 5 / 6 years ago. Since then I have seen the power of Hubspot Operations Hub (even the inbuilt workflow builder in Hubspot without the operations hub is fantastic) and Jira Automations (I cannot believe I am praising JIra...) really show the capabilities of other tools on the market, especially considering they allow for orchaestration of events using an easy to use building interface.

    Triggers / Automations are average at best in their current state and poor at worst.

  • Stephen


    One topic I forgot to mention in previous post was Side Conversations - particularly related to Child Tickets. At the moment, this feature does not feel as powerful as it could be.

    It would really enhance the parent-child relationship on tickets, if we could post / sync updates between parent / child tickets.

    For example, having the ability to post a comment to a parent ticket when a child ticket is Solved, with some placeholders about when the request was resolved, etc. This would enhance visibility, but also allow for a parent ticket to act as a full audit trail on the events associated with it. 

    In addition, being able to utilise the options to copy followers / copy fields in Trigger creation for Side Conversations would help. Going a layer deeper, having the ability to select individual fields to copy from a parent ticket to child would add even more power.

    At the moment, I am achieving this via webhooks.

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Hi Stephen Wouter Wolff Lan Margosis Anne-Flore Caire

    Thanks so much for providing such detailed feedback! 

    Some of the items you all mentioned are on our current roadmap, like expanding the data and operators available in triggers, finding ways to create more flexible conditional logic and how to better track changes and errors for triggers, so that is great to hear we are on the right track! 

    I'll work on parsing out the rest of your feedback to the PMs owning those areas to make sure it gets captured. 

    If you haven't already, please do fill out the survey linked

  • Tommy

    When we can expect automations UI update? They are dated, terrible, frustrating and eat a lot of administrators' time. 

    Making it the same as in triggers would be a huge step. We have a lot of automations and custom fields and it is almost impossible to manage already. 

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Hi Tommy 

    Thanks for providing your feedback! I've captured this in our product feedback tool. 

    I hear your frustrations and upgrading the automations UI is certainly being discussed to see where we can fit on our roadmap. For 2023, the team is focused on expanding the data available in triggers. Once we have more firm plans in place for Automations, we will certainly share. 


  • Tommy


    Thank you for the reply. We currently have 1400 triggers and 10 times fewer automations, but managing automations is 10 times more difficult :) 

    The main issue is filtering of course, the absence of. 

    But, maybe you can at least provide one fix that shouldn't take that many resources to implement? 
    Right now, all the fields in conditions and actions are in some random order. If they would be sorted in alphabetical order, it would be a huge huge help. We have around 300 ticket fields and sometimes finding the needed field takes a lot of time. I hope you could understand the frustration and at least provide with this small fix as full UI overhaul is not on the roadmap at the moment. 

  • Tommy

    Regarding triggers I often find myself creating a lot of similar triggers like:
    If Field1 = A then set Field2 A1

    If Field1 = B then set Field2 B1

    If Field1 = C then set Field2 C1

    Would be much more convenient to set it all in one trigger. Liquid markup would be PERFECT, as mentioned before. 

  • Patrick

    Do you use triggers or automations more? Why? 

    Triggers. The UI for automations is old and outdated, not fun to use and automations are more limited. The uncertain/fuzzy nature of when exactly they run is also a little annoying. As time sensitive automations can run up to 59 minutes after the set time. We mainly use automations to control the closing of tickets, as well as initiate an automatic de-escalation when a specific priority-based amount of time has passed.

    How often do you make changes to your triggers? 

    Anytime we need to add a new agent. We have a complicated system that automatically escalates and de-escalates tickets based on the group and user the ticket is assigned to. This is built on a custom ticket field, which when changed then directs a series of triggers to escalate or de-escalate the ticket.

    What is your most used condition in triggers?  

    TAGS: "Contains at least one of the Following"

    Do you find yourself repeating this condition in multiple triggers due to product limitations? 

    YES! We desperately need a "Contains all of the Following" option. Many of our triggers look for a combination of multiple tags. Since I cannot specify a bunch of tags at a time, like I can with the "Contains none of the following" option, I am forced to use multiple tag conditionals anytime I want to look for multiple tags.

    What is your most used trigger action?

    Add/Remove Tags are by far my most used Action. 

    Do you find yourself repeating this action in multiple triggers due to product limitations

    YES. Close to half our triggers exist just to act as And/Or logic groups. IF we could get the ability to group conditionals within triggers, it would simplify things immensely.

    What would be REALLY nice would be the ability to pull/transfer data from a follow-up ticket. We have a series of triggers that currently use tags to assign follow-up tickets back to the same Agent that the ticket was assigned to when it got closed. Many of our customers contact us months in advance, as there is a lot of lead time involved in our products. Often months will pass before they communicate with us again, usually when the event date is a few weeks away.

    If there was an "Assign to Previous Agent" action exclusively for newly created follow-up tickets I would be very happy.

    Also, I am gonna go create a feature request for a Tag Manager UI. We really could use a better way to get an big picture view of what tags are present on tickets (open, solved, closed) as well as the ability to dictate special rules for them.

  • Tommy

    I remembered two more things we are currently missing dearly.
    - the ability to add internal/public comments with a trigger. we use a lot of tips for agents, different reminders on how to behave with specific users, channels etc
    - the ability to use placeholders when setting the value to text fields. we have a lot of custom information in user and often need copying it to ticket

    for both of these cases we use API and webhooks which is not an ideal solution, to say the least 

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Hi Tommy & Patrick - Thanks so much for your input! 

    Tommy - a few followup questions:

    For comments, so you are thinking of using this almost as a tooltip for agents? How about the public comments, what is you desired use there?

    Do you mind expanding on what you are trying to copy over from a user? Would having access to a related user's field assist in your use case, or do you truly need to copy it into a ticket field? 

    Patrick - we are currently working on expanding the operators available in trigger conditions to have parity between similar data types. I captured the need for a 'contains all of the following' to identify a set of tags as well. This is an ongoing effort for the team after we get through the data expansion effort we are currently tackling, so hopefully more to come on that soon! 



  • Tommy

    Yeah, we are using internal comments as tooltips for agents extensively. Regarding public comments, the usecase is following: when we automatically followup user, we want this information in the ticket, so the next agent who sees the ticket had full information about our communication with user. One way to achieve that would be the ability to add public comment to ticket: user will be notified, and ticket will have a full story. But this can also be achieved by internal note as a separate trigger action, so yes, public comments are not that viable for us while internal is critical.

    Users in our instance are often created by our backend, with custom user fields populated. And when user creates a ticket, we need to show (to agents) those data from user custom fields among ticket fields. Of course, if it would be somehow possible to do with lookup fields, it would be enough for us. 

  • Bailey Whitaker-Lea
    Zendesk Product Manager

    Thanks for the details Tommy !

  • Riccardo Centomo


    • Do you use triggers or automations more? Why? 

    We use massively triggers and automations. We also use automations to manage the visibility of the ticket in the view and to show only ticket that have updates or are not managed from a certain time.

    Our issue is the tickets that are not closed but have had more than 100 automation audits occur during the life of the ticket are excluded from the hourly automations run.

    This limit is reached over the 50% of our ticket so this is the most product limitations that impact on our ticket management.


    Use Cases:

    We use massively the automations to hide and make visible the ticket inside the view. This has the advantage to show only ticket that have to be managed from our zendesk agents.

    We assign the due date to the ticket an so we can manage the time when the ticket has to be present in a view.

    The 100 automation audits occur during the life ticket limit is very restrictive product limitations.

  • davidc

    The UI tells me if a particular trigger has issues. Points to a non existing ticket types.
    It would be good to be able to get all these warnings via the api. Rather than have to manually look for all existing known issues if these could be found in one place that would be easier.


  • Sydney Neubauer
    Zendesk Luminary

    Do you use triggers or automations more? Why? 

    • We use triggers way more - usually with time based, you set them up and rarely need to look at them again. Plus the UI is very clunky in automations vrs triggers

    How often do you make changes to your triggers? 

    • We make changes daily - we work on adding new workflows, troubleshooting, onboarding, etc. We have to edit a trigger at least once a day if not more

    What is your most used condition in triggers?

    • Trigger via tags or groups.  

    Do you find yourself repeating this condition in multiple triggers due to product limitations? Do you find yourself repeating this action in multiple triggers due to product limitations?

    • All the time - for example, you can't have multiple "Any" scenarios. So if you want this trigger to fire either Web form or email but not API, but only for these certain groups, you have to create a trigger for each channel
    • Another limitation is that we use different signatures depending on the group. So we have to have multiple triggers for groups even though they essentially do the same thing. It would be better if it was a single trigger and then have statements where "if these groups/tags, use this action" and "if this group, use this action instead". we have 110+ triggers just for basic back and forth notifications

    What is your most used trigger action? 

    • Notify active webhook - we use this to set from addresses, add internal notes, look at profile, add parent/child ticket id, change ticket to another Zendesk instance, etc


    • New automation conditions: Automation Time-Based Conditions – Zendesk help
    • Schedule Trigger changes - ie. A lot of our changes are time sensitive and need to be coordinated. So someone is ready to test and the other is to click save. It would be best to schedule when to change so that only 1 is needed for the launch: Scheduled Trigger Activation/Deactivation – Zendesk help
    • Ability to create a trigger in a deactivated state - too many times do I click enter and it publishes the trigger and then I need to go back and deactivate it
    • Uniform UI for all changes - Views, automations, triggers
    • Ability to report on when automations, triggers fire and the tickets they fire on
    • When you are creating a trigger, it would be nice to be able to search for other triggers so you can compare your current trigger to another one without needing a separate window
    • Ability to drag and drop conditions within triggers. Sometimes I create everything in the Any condition and need to move it to the All condition instead
    • Ability to select trigger position - I have to search for a trigger to see what category it is in, unsearch, go to category then drag and drop trigger (which is difficult when there are 200+ triggers in a category. and then to find out it is in the wrong category too)
    • Have a better description in audit log of changes to triggers
    • Add Talk numbers as a condition - right now you have to use comment text which makes it impossible to use the filters to search for as it needs characters and can't search via numbers or symbols

Please sign in to leave a comment.

Powered by Zendesk