Trigger Received At

12 Commentaires

  • Dan

    I second this request

  • Zack

    Yes please!

  • Chaim Pollak

    amazon idea, very useful.

    since we do have a "Ticket channel =  is not" there s no big deal of adding a 'Ticket received = is not "

  • Tobias Hermanns



    We´ve a use case, where we want forward people to our Helpcenter and block Mail one by one...


    By over 100 Mail address it´s hard to setup 98, instead of 2.



  • Gernot Danner


    we also have a use case where we want to exclude certain email addresses via a trigger.

    a "received at IS NOT" option would really help here.

  • Nicole S. - Community Manager
    Zendesk Community Team

    Hi All - 

    Can you share additional detail about your use cases, i.e. how frequently the need comes up, what the impact to your business is, what impact a solution to this problem would have, etc.? 

  • Tobias Hermanns



    we´ve since years E-Mail address per country



    We know have experience with Zendesk Guide and develop our Self-Help Center.

    So from now onwards, we want customer change mindset from send E-Mail directly with sometimes "stupid question" which can be directly found in KB.

    So the way should be, that we force them using Web-Portal (Helpcenter) check KB, then raise a ticket and put all information in formular we create and we want to know before.

    So we disable (remove) mails one by one from trigger.

    In case of so many E-Mail adress we configured we´ve one "Priority Backup Trigger".

    This trigger only set Prio to Low and send a "Request received".

    If we can enhance this trigger with "not at" ... "blocked E-Mail" then we can fire only the Trigger for "support @... block with a Note "Please use Helpcenter in future"....



  • Nicole S. - Community Manager
    Zendesk Community Team

    Thanks for taking the time to add those details, Tobias. That's helpful. 

  • Scott Patterson

    Hi all,


    This would be great for me as well. My use case is:


    We have a couple of different incoming addresses, and we want to apply different trigger logic depending on how these tickets come in. This can mean different automated notes, different tags added, different sharing options etc.

    We have a default set of triggers, which apply to all ticket sources (web forms, emails on default email address etc), and then non-default set of triggers which apply to tickets that come in on a secondary email address.

    Without having an 'is not' option, it becomes more difficult and messy to try and make sure all our default rules apply to all sources EXCEPT for one or two email sources. If we try to do this with just 'is' options, we would have to apply these all in the 'if any of these criteria match' section which means we can't use it for other criteria on triggers. Adding a tag or something based on the source may be an option, but this also becomes more messy to manage compared to a simple 'not' option.



  • Philippe Rambaud

    +1, some country don't like to be spammed and would like not to recieve some emails that other countries want

  • Jimmy Rufo

    Absurd that this isn't an option.  I have a support team that needs to not act on tickets to a particular support email address, as it automatically gets routed to another team.  Not having this just creates noise and confusion, since I have these messages filtering into Slack.  Why on earth is this not an option!?!

  • Naomi Watnick

    +1 We need this too!


    Our use case: our TAMs should get assigned to tickets that come in from any method except for a specific email address.  


Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk