Amy Dee

Question

How are incoming emails threaded to tickets?

Answer

When an inbound email is received, Zendesk checks the email for references to existing tickets. This determines whether the email will be added as a ticket update or if a new ticket is created.

Zendesk checks three main references for threading emails:

• Elements in the email header
• Encoded IDs in the message body
• Encoded IDs in the Zendesk receiving address

1. Elements in the email header

In the email header, the References and In-Reply-To lines contain the message IDs for other emails in the same thread. Zendesk will check for those message IDs on existing tickets. If Zendesk finds a match, the email will be added as a reply to the matching ticket.

The email header is visible in the email source. See the article: Viewing the HTML and original source for incoming tickets for details.

For more information about troubleshooting email headers, see the article: Why do emails thread to the wrong ticket?

2. Encoded IDs in the message body

An encoded ID is a unique reference to a specific ticket. Zendesk includes an encoded ID by default in every outbound notification email, which helps match replies to the correct ticket.

An encoded ID can be added to any email body and is not exclusive to emails generated by Zendesk. The encoded ID must appear inside square brackets [1G7EOR-0Q2J] in order for Zendesk to detect the ID.

3. Encoded IDs in the Zendesk receiving address

Zendesk support email addresses may use aliases that include the encoded ID. For example, the email address for a ticket with encoded ID 1G7EOR-0Q2J in the mondocam subdomain would appear like this: support+id1G7EOR-0Q2J@mondocam.zendesk.com.

This structure helps allow the email to thread to the corresponding ticket, even if no other references are present.

This use of encoded IDs only works for Zendesk support email addresses and does not work for external support addresses.

How to access the encoded ID

You can find the encoded ID of a ticket by following the steps below:

• Use the {{ticket.encoded_id}} placeholder in macros or ticket comments to show the encoded ID.
• Use the Tickets API to view the encoded_id parameter. This approach allows API workflows to access the encoded ID without manipulating ticket comments.

Hi David Durr !

That is a valid security concern, and it's one that Zendesk shares. 

These account exports are always restricted to administrators. Agents don't have permission to see or initiate them. In addition, the account owner can restrict exports to administrators in specific email domains (or disable exports entirely). We have more information in this article: Restricting or deactivating account data exports. 

Those settings apply to the account export tools described in this article. It doesn't extend to the API. That said, while agents can access some data through the API, the Incremental Exports API endpoints are all admin-only as well.
 

I hope this helps!
 

Hi Riah Lao -

Correct again! Zendesk functions - including views, automations, and analytics - use the full timestamp of the SLA target. That means views should consistently show a 1:40 ticket ahead of a 2:20 ticket, even though they both show a “2h” badge. The badge is just there as a quick visual indicator for agents.

I hope this helps!

Hi there! 

Solving a ticket also fulfills all active SLA targets. This includes reply and update targets, which typically require a public comment. In your example, solving the ticket would fulfill the next reply time target, even if the agent didn't publicly respond to “Thank you.”

I hope this helps!

Hi Riah Lao 

Thanks for the question! Your example is spot on. If the time remaining is 2:20, the badge will round down and show “2h.” If the time remaining is 2:40, the badge will round up and show “3h.” The exact halfway point - 2:30 - also rounds down to “2h.”

SLA badges have three different units: minutes, hours, and days. They start displaying the next unit up when that unit rounds to 2. For example, a target of 36 hours and 30 minutes would round down to a “36h” badge. A target of 36 hours and 31 minutes would round up to 37 hours, which then rounds up to “2d.”

There is no unit above “days." If you have a 2-year target, you'll see “730d” in the badge. There is also no unit below “minutes.” When the target is at or below 30 seconds, you'll see “now” in the badge.

I hope this helps!

Hi Jon! 

At this time, there's no way to adjust how first reply time is measured. The system metric will start at ticket creation and end at the first public agent comment after that. The SLA target will wait for a public end user comment to get started (if the ticket was created with a private note).

You could create separate SLA policies for phone tickets. That wouldn't change the first reply target behavior, but it would allow you to manage those tickets and agent expectations separately.

I do have some good news. Our SLA team is hard at work on enhancements that will give users more flexibility over reply time SLA targets. That could help for workflows like yours. I recommend following our Announcements page for more information.

I hope this helps!

Hi Hannah! 
Schedules are applied to tickets, not SLA policies (or other business rules). For the SLA policy, you just choose between calendar and business hours for each target. If you choose business hours, the SLA will use the schedule associated with the ticket. 

Professional accounts only have one schedule, so there isn't much flexibility with business hours. Enterprise accounts can have multiple schedules, though, and they're controlled with business rules. That would allow you to create corresponding schedules and SLA policies for tickets in certain workflows.

We have more information about schedules here: Setting your schedule with business hours and holidays.

I hope this helps!

Issue symptoms

• End users receive a bounce back notification from Microsoft after they send an email to a support address.
• The notification starts with: Your message could not be delivered.
• The message includes an error or status code with 550 5.7.x.
• The emails don't reach Zendesk.

The text of the message will be different for each underlying issue. However, the main problem remains the same: the user's email was rejected before it could reach Zendesk.

Resolution steps

These errors are generated by Microsoft, not Zendesk. Zendesk cannot assist in resolving these errors. If your users suddenly report bounce back notifications and error messages, contact your email administrator. They will need to review the error message and your email configuration.

The email administrator for your email domain can investigate and resolve these errors. Microsoft may have updated its policies around automatic email forwarding, and it may affect support addresses that have been working smoothly for a long time. For more information, see this article: Forwarding incoming email from your existing email address to Zendesk Support.

Hi @...! A business hours badge could work, but it would require total consistency: one schedule that never changes; no holidays (or exhaustively communicated holidays); all users in the same time zone; no SLA targets in calendar hours, ever.

If there's any variation in any of those points, a business hours badge becomes ambiguous. Multiple schedules, schedule changes, different regions, and different SLA policies all impact how much time is actually left on a target. Agents could no longer take the badge at face value.

Even if there is total consistency, SLA badges round their numbers to hours (or days) when the target is far enough away. This means two tickets could both have a "2 business hours" badge, but one is due Friday at 4:50pm while the other is due Monday at 9:10am. Agents should prioritize the Friday ticket, but they need an easy way to know which is which.

SLA badges in business hours put a burden on agents. Before agents can act on a badge, they'd need to interpret that number in relation to the schedule and their current time. That mental math is taxing, even in simple environments. In more complex environments, it's prohibitive. 

SLA badges are designed to quickly prioritize workflows. It's important to ensure that they're all on the same scale, regardless of account complexity, and that the scale is intuitive at a glance. That's why badges show real time remaining. This allows agents to see accurate deadlines, without any extra effort required.

I hope this helps!

Hi Leif Cederblom! At this time, Explore only captures SLA durations after the target has been fulfilled. There is no way to create an Explore report that shows live SLA counters for breached tickets. 

This is due to how Explore syncs data. It isn't a live feed; it pulls data at periodic intervals. That means it has no way to maintain live durations for metrics. Explore can't tell whether an SLA has been fulfilled until after the next data sync, so durations would be stale.

If you need to monitor active SLAs in real time, we recommend using Views. You can export Views to CSV as well if needed. Explore is better suited for historic reporting.

I hope this helps!