• Blueground

  • April 05, 2021 21:42

  test comment. from me.

• Dan Cooper

  • April 06, 2021 17:00

  Community Moderator

  @...,

  I've worked in an environment that had a similar scenario as yourself.  If you need to capture the initial recipient address you can capture it in a custom ticket field. 

  1. Create a custom text drop-down field for Original Support Address. Add all of your support addresses as options.
  2. With as many support addresses as you state, it's probably worth creating a Trigger Category for this, as you'd need a trigger for each support address to keep this hands off
  3. Create a trigger for each support address that populates that field on ticket creation.  You might even consider setting this field for your web based tickets that don't typically display an original support address (recipient address doesn't exist on a web ticket until you add it - you just respond from the default support address). Something like:

     ALL
     - Ticket | Is | Created
     - Received at | Is | {support address}
     
     ACTIONS
     - Original Support Address | {support address}

     OR

     ALL
     - Ticket | Is | Created
     
     ANY
     - Channel | Is | Web form
     - Received at | Is | {default support address}
     
     ACTIONS
     - Original Support Address | {default support address}

  4. Use a custom field placeholder when you need to access that value: 

     {{ticket.ticket_field_option_title_<field ID number>}}
     

  5. If you don't want your agents touching this field, you can exclude it from your forms, or you can use an app from the Zendesk App Marketplace like Ticket Field Manager.  These won't entirely block the field from being updated (macros, bulk actions, etc could still update them) but it would hide the content from your ticket forms. 

  I have found this sort of field useful for things like View columns and groupings as well as Zendesk reports (though I think that his been resolved in Explore since I had to work with these workflows). 

• Blueground

  • April 06, 2021 20:38

  Hey @...!

  Thanks for the thorough response - these are some cool ideas! 

  For this particular need, it's actually not the "received at" support address. We operate thousands of Apartments, each has it's own email (e.g., NYC-123@.... or SFO-555@... or WDC-6@...). These all then forward again to a ZD support email for the city the apartment is in, and we have those built out. But I need to identify which one of those original emails was the original "to:" recipient on the email. 

  So while I like the idea, the actual issue is that I can't use a filter like "Received at" in any triggers to identify these cases, versus normal tickets where a client emails our support emails for those same cities. 

  Thank you so much for contributing and helping - I love it

• Dan Cooper

  • April 07, 2021 15:05

  Community Moderator

  @..., 

  Some other possibilities you can consider might be:

  Is it possible to remove the forwarding layer and setup each apartment address as a support address directly within Zendesk?  You could respond using the apartment address or you could utilize a Zendesk app like Select an Address to choose an out going city address if you wanted an address to be represented at that level.  If your model allows for you to have cities as groups, you could have the app automatically set the outgoing address for you based on any triggers you have setup to route to groups which may look like this: 

  ALL
  - Ticket | Is | Created
  
  ANY
  - Received at | Is | {City A - support address 1}
  - Received at | Is | {City A - support address 2}
  - Received at | Is | {City A - support address 3}
  
  ACTIONS
  - Group | {City A}

  I'm not sure how Zendesk implemented their paid option for Select an Address, when we used a similar model we had to build our own as there were no options on the marketplace at that time for automated support address selection. It looks like it works the same way as what we had built though.  You might also consider checking the marketplace for other apps as I've seen a few more pop up like Reply to Email Selector and Reply From.  I haven't used either of these, but you may find some value in checking them out. 

  Is it possible to include any text in the body of the message when it's forwarded with your email forwarding process?  If your emails come through a web form, this would be a simple option that doesn't require you to do too much rethinking of workflows for your team.  You could use a trigger that sets a dropdown field similar to above based on the text provided in an email or subject using a condition like this: 

  ALL
  - Ticket | Is | Created
  - Received at | Is | {support address}
  
  ANY
  - Subject text | Contains the following string | {apartment string}
  - Comment text | Contains the following string | {apartment string}
  
  ACTIONS
  - Apartment Address | {apartment address}
  

• Qin Brian

  • October 28, 2021 09:31

  I work in this way

  https://kwaisupport.zendesk.com/api/v2/search.json?query="recipient": "customer-service@xxx.com"

Please sign in to leave a comment.