How can I identify the recipient "To:" email address of an inbound Ticket?

test comment. from me.

@Nick Budinicich,

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

Hey @Dan Cooper!

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

@Nick Budinicich, 

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}

I work in this way

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

Hello,

We are getting emails and replies as updates to wrong tickets, because that email has already been received by another team in a different context.

I understand that this is related to message ID.

I'm trying to create a trigger to add an internal note if there is a mismatch between group and email, but it's not working, so the ticket can be reassigned correctly.

The logic should be right. Please help, if you can. I need to capture the "To:" email in this context.

So:

ALL
- Ticket | Is | Updated
- Received at | Is | {support address for team "example"}
- Group | Is not | "example"

ACTIONS
- Add internal note about mismatch of recieved at email and group.

Thank you, Paolo, I will contact Zendesk support in this case.

The answer is that the "Received at" refers to the when the ticket was made, which is why it is not possible to use the trigger to identify updates to "Recieved-at" emails on the ticket.

+1 Being able to identify/extract "To:" of the original email, as all tickets show as "To support group", even if the support group is in CC in the email conversation.

In b2b settings, issues are often solved in teams, resulting in the support team being in CC. Agents would appreciate knowing up front if the ticket is actually directed at them or if they are in CC, as they waste time figuring out if the ticket is actually for them to reply to.