Trigger Received At

I second this request

Yes please!

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 "

+1

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.

+1

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.

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.? 

Nicole,

we´ve since years E-Mail address per country

support@....de

support@...nl

support@...at

..

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"....

/Tobias

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

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.

Thanks,

-SP

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

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!?!

+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.  

+1 for this request, seems like a relatively simple ask!

+1, I am trying to set up notifications for received tickets while using multiple email addresses, and I am finding it almost impossible to prevent sending 2 notifications . 

+1

Having consistent logic operators on each trigger condition would be a huge win. Not necessarily just received at. 

Any update on this? It's now 7 years old, has a decent discussion around it, lots of votes and it's a simple request. 

We're constantly told that feedback in these forums will be picked up and reviewed based on interaction (a poor metric in my opinion) but here we are. 

@nicole17 Pinging you as you've have the most recent input from Zendesk as well as @Adi Schnall who knows my feelings on this method. 

Hi Nathan - 

We will check in with the product manager for this request. It's only received 1-2 votes/comments a year, and isn't one of the more highly requested features, which may be why it hasn't received much attention in the past. But we'll see if we can't find out what the PM's perspective is! 

Popularity of a request should not negate its usefulness or merit.
Just because one hundred other clients have not encountered this same problem doesn’t mean it does not exist. Equally, because the majority of Zendesk users have realised the interaction with internal CS is nearly meaningless doesn’t mean we have ideas/requests that are not worth exploring.
I regularly refute the prompt by ZD agents to “post feedback to the community forums” because I know there’s very little uptake. This thread seems to be evidence of that.

This is also one of those things that would likely be very easy to implement if it just has someone work on it for a short period of time. Even if the perceived benefits are low (as not many comments per year), the cost of doing this is also very low compared to other bulkier feature requests, doesn't make sense to compare them all on the same scale of votes & comments. Surely that context matters and should make it easier to get someone to work on this?

Thanks everyone for the feedback, it’s always helpful to hear from customers and we do read all the threads and use cases. This one seems relatively simple but the team will need to hash it out with engineering and balance it against the other initiatives that they have coming. Thanks again for the feedback and the team will post again when they have an update.

@chris142 are we talking days, weeks, months or years again? 

Another voice for IS NOT operators checking in. Once you get large/complex enough and could have many attribute values you may need to filter your work by, it's faster, easier to read and maintain workflows by excluding a specific value than include every other one possible. 

Example: Let's say I run Alphabet Inc. (no, not that Alphabet). Let's say I have 26 emails, each named for a letter of the alphabet. A@alphabet.com B@alphabet.com etc.

Now, Team X@alphabet.com is special.  They work on niche, time-sensitive issues. They're the best at what they do and we don't want to have any distractions or their work get picked up by other teams by accident. In fact, it would be a Bad Thing™ indeed for our business if non Agent X agents touched these tickets. 

I want my ticket views and rules for the rest of the teams in Zendesk to not deal with Team X's stuff.

With today's operators, a view that needs to exclude X@alphabet.com would have the ANY section of the config looking like:
Ticket Received at IS A@alphabet.com
Ticket Received at IS B@alphabet.com
Ticket Received at IS C@alphabet.com
Ticket Received at IS D@alphabet.com
Ticket Received at IS E@alphabet.com
Ticket Received at IS F@alphabet.com
Ticket Received at IS G@alphabet.com
......
Ticket Received at IS W@alphabet.com
Ticket Received at IS Y@alphabet.com
Ticket Received at IS Z@alphabet.com

It would be much more maintainable and easy to read if I could instead apply an IS NOT operator

Ticket Received at IS NOT X@alphabet.com

Look how much easier that Ticket view would be to interpret!

(Yes, I know there's other ways we can work around this, like tagging Team X's cases when they come in with a trigger and having views exclude that tag, but that's going to require an Admin to setup the rule, meaning managers can no longer self-serve their View management, and adds noise to our Triggers. It's just that, a work around, and work arounds applied at scale lead to more workarounds having to get created later until the whole instance is built on bandaids and prayer).


Let's go a step further. Next year, we acquire Numbers Inc., fine purveyor of all things numeric. Now we need to add more emails to our Zendesk and there's a lot more numbers than letters of the alphabet. (Think 1@company.com, 2@company.com) Team X's goals remain unchanged however, they need that laser focus to deal with problems relating to the alphabet's most mysterious letter.

In today's world without IS NOT operators, we're going to have to update every view with additional conditions to deal with that. That monster View example above? It just got way harder to read and requires frequent updates for each new number@ address we need to support. That makes admins sad. A deep, soul-crushing kind of sad. 

In a world where we would have an IS NOT operator, no maintenance is required to the initial trigger as the emails from Numbers Inc. are not X@alphabet.com

In summary, it would really mean to admins everywhere a lot if Zendesk devoted effort to have any operators in views/triggers/automations be able to be applied in both selective and exclusionary manners. 

Thanks for reading :)

The other important thing to note on top of Dan's example is if you're using the ANY section of the trigger config to add all those 'ticket received at' addresses, it means you can't use any other ANY conditions in that trigger.

If you also needed to have that kind of trigger only apply to a handful of subject strings for example, you can no longer have your ANY condition be subject contains string 'a b c' or subject contains string 'd e f' or subject contains string 'x y z' - so you lock yourself out of options to make your triggers work properly without making duplicate triggers or applying tags via other triggers for every kind of situation you need. Sometimes depending on the complexity this just becomes less and less feasible.

Another +1 on this.

My use case is I have a few separate email addresses we receive tickets at for different categories of issues (general vs. privacy as an example). For the general queue, I don't want tickets received at privacy@domain.zendesk.com to go into the general queue of tickets received at support@domain.zendesk.com, but tickets received at a tertiary email address (as an example, billing@domain.zendesk.com) I would want in that queue. Having a "received at IS NOT privacy@domain.zendesk.com" would accomplish this, and I haven't found an alternative solution that would do it as cleanly.

+1

We encounter this many times within our instance as we have hundreds of additional email addresses.