Blocking the email channel

Return to top
Have more questions? Submit a request

24 Comments

  • Jean-Michel WEISS

    sounds good, i did the same thing, but i want to allow my organization to send ticket, and when i say org, i mean all mail addresses from my org. i believe that if i have also associated the domain myorg.com... in my organization. then i can add a condition like organization is not my org, and it takes in account the domain ?

    0
  • Brett - Community Manager
    Zendesk Community Team

    Hi Jean-Michel,

    As you stated, I would recommend adding the Organization > is not > (org name) under Meets all of the following condtions so emails sent from that organization are not immediately closed when the ticket is generated. If you have your domain associated with the organization within your Support account then that solution should work :)

    Hope this helps!

    0
  • Jean-Michel WEISS

    it seems logic and it's what i did :-) i was just afraid  that it is only applied on the users created in the org and not all the mail adresses coming from the org. THX again zendesk ROX !!!

    0
  • Brett - Community Manager
    Zendesk Community Team

    Happy to help Jean-Michel!

    I do want to clarify that if you do go this route then you'll want to make sure those users belong to the organization you've set up. If you're including the domain in your org within Zendesk then they will automatically be added and you should be all set.

    Cheers!

    0
  • Barrett Smith

    This works well to block ALL incoming emails, but what if we have two separate email addresses for customers to use and I only want to prevent them from using one of them?

    For example, I want to stop customers from being able to email support@mycompany.com but allow customers to still email design@mycompany.com.

    The trigger above will stop all incoming email, and I only want to stop it when it's sent to a specific internal address.

    0
  • Jean-Michel WEISS

    if you associate each mail address to a specific brand ( depends of your zendesk subscription), then in the trigger, you can use the condition  "brand is not design" for example...

    0
  • Chris Wooten

    IS there a way to block inbound CC from creating a ticket?

    0
  • Devan - Community Manager
    Zendesk Community Team

    Hello Chris,

    So, unfortunately, no this isn't currently possible. You do have the ability to block an e-mail you no longer want contact from but disabling the ability from an email address isn't a feature the platform supports.

     

    0
  • Justin Federico

    This might be obvious to some but I wanted to know if this would affect customers replying to a ticket via email after the ticket has been created. I see the trigger is looking at the "ticket created" condition.

    We want tickets to be created via the Help Center but we would still like the end-user to be able to respond to tickets via email.

     

     

    0
  • Søren Reinewald

    @justin - When the trigger is set to Ticket is Created, it will only trigger when the ticket is created, and NOT on updates which is what happens when users repond to tickets via email.

    1
  • Søren Reinewald

    Another question on this. When I as an agent forward an email from someone, I would like to allow myself to use the email channel.

     

    But setting the organisation to the agents organisation will not work, as when forwarding as an agent, it will automatically set the requester to the sender of my forwarded email.

    Any tips on this where it automatically converts the requester because of a forward from an agent? I can't use "submitter" in triggers apparently.

    0
  • Brett - Community Manager
    Zendesk Community Team

    Hey Søren,

    Just to confirm, are you wanting to prevent the ticket from setting the original sender of the email as the requester of the ticket. 

    What you could do is set the requester of the ticket when you forward the email over by using the Mail API as mentioned in the article I attached. 

    Let me know if that doesn't get you the results you're looking for.

    Cheers!

    0
  • Zach Proa

    In our use case, we would like for all tickets to be submitted via Help Center. We do not want any tickets coming through email, period.

    Reading through this article, seems like this will help satisfy this requirement. That being said, it looks like a ticket will be opened no matter what once an email is submitted (even if immediately closed via trigger). This throws off our metrics that we keep. How can it be set so no ticket is created at all? 

    Looking forward to a response!

    Thank you!

    0
  • Brett - Community Manager
    Zendesk Community Team

    Hey Zach,

    The best option here would be to set up your trigger to also tag these closed tickets. You can then exclude any ticket that contains that tag from your Insights or Explore reports. More information on tag reporting in the following articles:

    Let us know if you have any other questions!

    0
  • Justin Federico

    How do we prevent the follow up ticket being created if an end-user replies to the response from the "Blocking Emails" trigger? The trigger closes the ticket but the end-user can still reply.

    FYI - I am only trying to block tickets being created via email. I want the requester and CC's to be able to update tickets via email.

    Update: The follow-up ticket does not use the email channel. I was able to create another trigger to block the follow-up ticket. 

    0
  • Brett - Community Manager
    Zendesk Community Team

    Hey Justin,

    There isn't a way to block the user from replying to that particular email. The only thing your trigger can do is automatically close the Support ticket that is created if they're to reply back.

    Let me know if you have additional questions for me!

    0
  • Justin Federico

    Does blocking the email channel reduce or eliminate Suspended Tickets?

    0
  • Brett - Community Manager
    Zendesk Community Team

    Hey Justin,

    It doesn't stop emails from being delivered to suspended tickets, however, if the email channel is not a supported channel then it should eliminate the need to check your suspended tickets view. Majority of content in the suspended view comes from the email channel.

    Let me know if you have any other questions!

    0
  • Iris Corenevsky

    We are about to launch a ZD instance for our internal employees to use. I'm trying to figure out a trigger or other method for not allowing email from our own domain unless it is from two specific email addresses - we want the employees to log into the Help Center and submit a request that way rather than via email.

    I tried a trigger that blocked emails from our organization which worked partially - it sent them the notification that a ticket was not created and auto-closed it. BUT I can't figure out how to tell the trigger not to fire if the email is received from either of those two emails.

    Since our agents and our end-users are all in the same domain/organization, using the white and blacklist doesn't seem to work either - I tried that and got a warning:

     

    Does anyone have any tips for me? I'm new to the Admin side of ZD.

    0
  • Heather Rommel
    Community Moderator

    Hi Iris Corenevsky,

    I wonder if one of these options might work for you:

    Option 1:

    Put in a Trigger that says 

    Channel...Is...Email

    Requester...is not... user 1 (user allowed to email you)

    Requester...is not...user 2 (user allowed to email you)

    Action:

    Status...Solved

    Add tag: use_form

    Then clone your Request Solved trigger and add the use_form tag. Modify the content of the email to say something like "Sorry we had to close your request. Please go to xxx.xxx.com to submit your tickets going forward. Thank you."

    Don't forget to go to your original Request Solved trigger as well as your Request Received trigger and add: Tags...contains none of the following...use_form  <-- this is so that they don't unintentionally fire off.

     

    Option 2:

    Same as above but if you anticipate the users changing frequently, perhaps you want to add the tag to the user profiles rather than using their names in the trigger.

     

    As always, I suggest testing, test again, and test one last time, with both agents and end user accounts to ensure it works as designed.

     

    Hope this helps!

    0
  • Iris Corenevsky

    Heather Rommel thank you for the response! It made me realize I may not have adequately captured my ask.

    I need our agents who also monitor our group email inboxes outside of ZD (for example, hr@ourdomain.com) to be able to forward emails from external parties that are appropriate for inclusion in the ticketing system. We don't want all of the emails sent to those addresses to funnel into ZD since some of them are sensitive and better handled outside of ZD.

    I've read a bunch of articles and community posts and am still having trouble figuring out the way to do that.

    0
  • Heather Rommel
    Community Moderator

    Hi Iris Corenevsky,

    Ah, I think I see now. I would suggest adding those group email boxes as Agents to your Zendesk if you can monetarily swing it. Because then you can forward them in and utilize the Email API to set the Requester, Group, etc. More on those # commands here: https://support.zendesk.com/hc/en-us/articles/203691006-Using-the-Mail-API-to-update-ticket-properties-from-your-inbox

    Let me know if I missed anything!

    0
  • Fredrik Tuvlind

    If i were to block the email as listed above. Would our customers still be able to answer their tickets in the email assuming the ticket has already been opened? Our goal is to prevent new tickets being created from email but still having the option for the customer to use the email conversation.

    0
  • Austin Lacey
    Zendesk Community Team

    Fredrik Tuvlind

    Thanks for your post! If you follow the steps in creating the trigger as defined above in the screenshot then it will only prevent new tickets from being opened.

    Existing tickets that are already open would not be affected by that trigger since it contains the condition:

    • Ticket is created

    As a result, the trigger would not run on tickets that already exist. I hope this information helps!

    0

Please sign in to leave a comment.

Powered by Zendesk