Upcoming changes to email behavior

Have more questions? Submit a request

94 Comments

  • Frank Lück
    Comment actions Permalink

    Hi guys - can we assume that you only target tickets - created via channel email? Confirmation would be appreciated - just to make sure that creating tickets on behalf of an end user via API is not affected by this change. I have seen that you stated you implement on mail relay level - but need to be 100% sure here. Many thanks!

    7
  • Brad Marshall
    Comment actions Permalink

    Ditto what Frank Lück said.

    0
  • Kevin M. Nathanson
    Comment actions Permalink

    We make heavy use of API-created tickets, and we have received the alert email; please clarify the situation with regards to API-generated tickets.

    0
  • Max McCal
    Comment actions Permalink

    Hey, all - 

    There are three cases in which the placeholder is not suppressed. If any of these is true, the message will still be visible.

    • If the ticket is created by an agent, the placeholder will work as expected
    • If the trigger's email notification will be sent to an agent, the placeholder will work as expected
    • After the first comment on the ticket, the placeholders will all work as expected

    Channel does not come into question here. Could someone give me an example of the call you're making to create these tickets? I'm fairly sure you're describing is a situation where the agent is the one creating the ticket, but I'd like to be certain as well. If your organization is creating the ticket, we don't expect the placeholders to be suppressed.

    0
  • Brad Marshall
    Comment actions Permalink

    So, an end-user creating a ticket from the UI (not the email channel) cannot get a verification email with a copy of their submission?

    2
  • Daniel Ertman
    Comment actions Permalink

    Max McCal : here's our workflow:

    1. Agent does something
    2. We process the event in our system
    3. We want to sent the end-user a notification of what we did
    4. We create a ticket for that notification email - the entire contents is the notification.

    So for that ticket in 4:

    • the requester is the end-user
    • the submitter is an API with admin role
    • the comment author is the end-user
    • the channel is API

    what is unclear to us is "If the ticket is created by an agent". It's submitted by an admin (via API) in our case, requested by the end-user. "Creater" isn't an API field.

    0
  • Max McCal
    Comment actions Permalink

    Brad Marshall They can get a receipt email with the ID and a link to the ticket (if you're using that functionality), but they will not see a copy of their submission in that email. This functionality has been exploited by spammers to the extent that we can no longer support this behavior.

    0
  • Max McCal
    Comment actions Permalink

    Daniel Ertman Allow me to double check, but our intention is that this should be supportable. Given that "the submitter is an API with admin role" we want to support this.

    2
  • Michael Fischer
    Comment actions Permalink

    Can you make your change default but give us the option to display it?  

    4
  • Dan Ross
    Comment actions Permalink

    In the case of a user submitting a ticket via the help centre form, if we sent a confirmation email with the contents of their message, would that still be suppressed?

    Is there any means to identify which triggers have the troublesome criteria? In some cases, accounts will have hundreds of triggers and there's no Rules Analysis entry for placeholders..

    2
  • Max McCal
    Comment actions Permalink

    Keith Host - Agent comments will still be sent to your end users. The only change is that they will not receive their own comments back to them upon ticket creation. All comments after the first and all comments authored by agents will be sent out as usual, so your communication workflow will not be affected. Email correspondence between agents and end users will not be affected.

    Dan Ross - Yes, in that case the placeholder would be suppressed. The trigger would still send an email, but the content generated by the end user would not be included. If you'd like some help looking through your triggers, we can provide assistance. Submitting a ticket to our help center or support@zendesk.com should be a good way to start that.

    1
  • Keith Host
    Comment actions Permalink

    Max McCal - Thanks for the clarification.  Makes much more sense now.

    0
  • Jorge Gonzalez
    Comment actions Permalink

    I need assistance with this, can this be optional? We have triggers created when we receive a form submitted by the end user so our boss receives a copy. How can we continue doing this with this new set of rules? Our boss does not want to sign in to ZenDesk, she only wants a copy of what is received thru that form, and us agents work the submission as a ticket.

     

     

    1
  • Dan Ross
    Comment actions Permalink

    Jorge Gonzalez if your boss is a ZD agent, then it sounds like the placeholder will render as expected. This reads that only non-agent users are affected when the email is sent. 

    0
  • Max McCal
    Comment actions Permalink

    Jorge Gonzalez - Targets should not be affected. You've set those up manually, and they are not the standard kind of email we're worried about here.

    0
  • Jorge Gonzalez
    Comment actions Permalink

    Max McCal so targets will receive the copy? How would it be displayed in this case? Do I need to edit my placeholder?

    0
  • Max McCal
    Comment actions Permalink

    The placeholders will not be suppressed in emails (or any other communication) to Targets. I'll get our documentation cleared up to mention that.

    1
  • Dan Ross
    Comment actions Permalink

    Jorge Gonzalez I don't work for Zendesk, but I doubt very much that trying to get more agent subscriptions is the reason for the change, the concerns spam issues outlined above are real.

    If not addressed, this issue risks lowering the global trust for messages sent from Zendesk mail servers. If Zendesk gets flagged as a spam service, many mail clients will start putting Zendesk-sent emails into client spam folders, which impacts all Zendesk customers. I think we can all agree that we want our customers to receive our emails from Zendesk reliably :)

     

     

    8
  • Jorge Gonzalez
    Comment actions Permalink

    Max McCal thank you for the clarification. I was worried because we really depend on that option. 

    Dan Ross I agree, it's just that the external target was not in the initial documentation, that is one of the reasons I brought it up. Regarding Spam, I do most definitely agree.

    0
  • Brad Marshall
    Comment actions Permalink

    I can see how a spam could occur by creating a ticket by the email channel, but how would it occur through the Help Center UI?

    0
  • Max McCal
    Comment actions Permalink

    Brad Marshall - The Help Center was actually the first target our spammers attacked. If you go to any open help center and enter my email address in as the requester, I'll receive that email. They've actually created scripts to automate that action and send hundreds or thousands of spam messages pretty rapidly.

    1
  • Brad Marshall
    Comment actions Permalink

    Oh, so in my environment you have to be signed in to create a ticket. And to be signed in you have to have a verified email address (from my understanding). So, under my scenario, we wouldn't have this problem but the suppression is still imposed, correct?

    0
  • Max McCal
    Comment actions Permalink

    At the moment, yes. We're going to quickly discuss, as I think we can create some limits around this so that if your account doesn't allow unauthenticated users to create tickets, we would not apply this logic. 

    9
  • Matt Faircloth
    Comment actions Permalink

    My account also only allows authenticated users to create tickets in our Help Center. We would also vote to apply certain logic where this doesnt apply if an end user is authenticated. Thanks!

    2
  • AimeeS
    Comment actions Permalink

    I would also like an opt out. I hate it when I'm the customer and don't get an immediate record of what I've sent. Many, many times as a customer I've gone back and referred to what I submitted. For example, my webhosting company does not include my comments when I submit and it is literally the thing I hate most about using them. I've taken to writing elaborate subject lines so I can remember what I originally said, but that is limited and I have to remember every time to do it.

    I get the need for a solution to spammers, but i would like another solution that doesn't result in poorer service to my customers. If bots are sending thousands of emails at once, wouldn't there be a way to limit based on that? Perhaps there are zendesk customers who have that many tickets being auto acknowledged at once, but it could be based on how many usually go out and then see a surge and then auto default to an "attack" response email that suppresses the information . For example for my wordpress website I get notification if there are is a big uptick in logins or attacks based on my normal level and I can set it up to do various things when certain thresholds are reached.

    3
  • Max McCal
    Comment actions Permalink

    Hi, Aimee - 

    We've taken a number of different steps to attempt to stop these attacks (and we have other solutions in the works), but the size, scale, and sophistication of these attacks is out of hand, At this time we cannot in good conscience leave open a vulnerability which allows any individual to arbitrarily push content through our system to another individual. We are going to explore allowing these messages to continue to go out when the customer has logged in, or when your account only accepts requests from authenticated users. The responses here have given us some great things to consider, and we'll post some updates soon.

    2
  • AimeeS
    Comment actions Permalink

    For my business it wouldn't work to make them login or be an authenticated user - too many steps for people who are new customers with questions - i would never create a user account to ask a new company a question. And my people are not technically savvy enough to login when they have another question on another day, it's already hard enough for them to login to the website to get access to an order they placed.

    But if there was no way to stop them on the backend without affecting customers, allowing it at least for people who have created previous tickets would be better than blocking it for everyone. It would only then affect new potential customers and less likely to affect existing customers (unless they have never asked a question before). 

    0
  • Max McCal
    Comment actions Permalink

    Jorge Gonzalez I've just confirmed for certain that Targets will not be affected. I've added a note to the article.

    0
  • Gerben Meijer - Itrica
    Comment actions Permalink

    We use the API with the credentials of an Agent to create new tickets on behalf of (non-agent) end-users. These tickets use the end-user email address as the requester, and adds another non-agent user to CC. The reason for this is that if the end-user replies, those replies (either by the end-user or the person in CC) will still be supported.

    You haven't clarified explicitly whether if this workflow will break yet. Can you please let us know?

    0
  • Ryan W
    Comment actions Permalink

    Hey Gerben Meijer - Itrica -- That workflow should remain intact/ not break. Any agent submitted ticket (including via API) will remain unaffected/ have the placeholders expand on ticket creation.

    This only affects when an enduser creates/ submits the ticket themselves, and then receives a notification immediately upon sending. Subsequent updates (when using ticket.comments_formatted) will still include the original reply as you would expect upon update (Placeholder reference). The comment will still also be present in the Web URL itself (so using {{ticket.url}} will get them a link to the full history of the ticket).

    Just to reemphasize, the placeholders not rendering will only occur if all of the following conditions are true. If all conditions for the notification aren't met, nothing will change: 

    1. The recipient is an end-user
    2. The creator of the message is an end-user
    3. The trigger fires upon ticket creation


    You can see this work already through any ticket you submit at support [at] zendesk.com (as we have altered the triggers to not include the placeholders already) if you would like an example, otherwise new trials do not include the behavior that is being suppressed by default either (feel free to spin one up to give it a try).

    Hopefully that helps!


    0

Please sign in to leave a comment.

Powered by Zendesk