Pesquisas recentes
Sem pesquisas recentes
![Ben Fulton's Avatar](https://support.zendesk.com/system/photos/1900069666484/profile_image_1263169339250_10557657.jpg)
Ben Fulton
Entrou em 16 de abr. de 2021
·
Última atividade em 04 de jan. de 2024
Seguindo
0
Seguidores
0
Atividade total
29
Votos
0
Assinaturas
15
VISÃO GERAL DA ATIVIDADE
MEDALHAS
ARTIGOS
PUBLICAÇÕES
COMENTÁRIOS NA COMUNIDADE
COMENTÁRIOS EM ARTIGOS
VISÃO GERAL DA ATIVIDADE
Atividade mais recente por Ben Fulton
Ben Fulton comentou,
I haven't seen this question answered yet. We have a ticket submission form that we would like to offer to *all* of our internal users, including some users who are agents in our Zendesk instance. However, the issue we are running into is that any Zendesk agent who follows a ticket form URL is taken to their agent homepage, not to the submission form. What can we do to override this behavior for at least some of our Zendesk agents?
Exibir comentário · Publicado 04 de jan. de 2024 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
This migration broke emails to CCs on shared tickets for us, and I can't find any mention of shared ticket behavior in these docs. Is this a known issue, and do you know if there is a workaround?
This appears to be the situation:
- A shared ticket consists of copy A on instance X and copy B on instance Y. Copy A may have different CCs from copy B. Formerly, the CC notifications for copy A were handled by an inborn business rule on instance X, and the notification to the requester (and presumably the CCs for copy B) were handled by a trigger on instance Y.
- After the migration, there is NO LONGER an inborn rule for notifying CCs on instance X. Instead, notification of CCs would be handled by a *trigger* on instance X that notifies the requester *and* the CCs. However, this trigger is *suppressed* by an inborn business rule as Zendesk does not want to email the requester on both instances.
So we appear to be left in a situation where it's not possible to notify CCs on a shared ticket on instance X. Since there is no rule in email notifications in triggers for "CCs only", there's no way to build a trigger that will send to CCs and not the requester. Is there a solution that we are missing?
Note that in this case, we have upgraded instance X to the new CC/Follower experience, but not Y. I assume that does not matter, since notification of the CCs for copy A would only happen on instance X. Is there any special handling of shared tickets that requires both instances to be upgraded to the same CC/Follower experience?
Exibir comentário · Publicado 31 de ago. de 2022 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
We are frustrated by this miss in the reporting as well. I would like to report open Problem tickets sorted by Incident count to help our engineers prioritize fixes.
Exibir comentário · Publicado 05 de mai. de 2022 · Ben Fulton
0
Seguidores
4
Votos
0
Comentários
Ben Fulton comentou,
Hi Orsolya,
I just wanted to see if the release date for this dataset has firmed up at all, and if it will be available soon as a beta test if we can opt-in. We have a team that could really use more detailed reporting on a topic that we are using for product suggestions.
Exibir comentário · Publicado 05 de jan. de 2022 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
Hi, I'm looking for some more precise answers about what Contributors can access.
"...for instance, contributors can view some tickets, but cannot respond or otherwise interact with them."
This seems unnecessarily vague—*which* exact tickets can the Contributor role view? Tickets assign to their group? Tickets with some other qualifier?
Exibir comentário · Publicado 21 de jun. de 2021 · Ben Fulton
0
Seguidores
6
Votos
0
Comentários
Ben Fulton comentou,
Hi Heather,
Thanks! We don't have a need for this add on aside from outputting lists, so I'm hesitant to spend any time with it unless we know it can definitely create a customer list from a user segment. I don't see user segments mentioned in the section about creating customer lists.
Exibir comentário · Publicado 15 de jun. de 2021 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
Is there any way that we can export a list of the users in a user segment to CSV/spreadsheet, either from Guide or via Explore?
Exibir comentário · Publicado 14 de jun. de 2021 · Ben Fulton
0
Seguidores
2
Votos
0
Comentários
Ben Fulton comentou,
Hi Graeme,
Unfortunately, our values do not look like numbers, so I tried building a metric that maps the string values to integers via a switch statement, but I am not getting any results.
IF [Changes - Field name] = "Escalation Level" THEN
SWITCH [Changes - New value] {
CASE "Customer Service": 1
CASE "Product Support": 2
CASE "Engineering": 3
}
ENDIF
I have verified that the first ticket result does have some updates that should register:
Am I missing something obvious here?
Exibir comentário · Publicado 11 de jan. de 2021 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
Our tickets have a multi-select field that we use to track the ticket escalation path through multiple tiers of support. If a ticket is assigned to one of those tiers, that tier's value will be added to the field for that ticket.
We would like to build a report that only shows the *maximum* escalation level for each ticket over time. So, for example, if a ticket has the values of both V1 and V2 for the field, we would like to *only* count the ticket on the chart as V2. Currently, when I build charts using this field we see tickets double-counted, showing as both V1 and V2 (where the metric is Count(Tickets) and the Rows are the field in question).
How would I compose an Explore metric or attribute that only reports a single "maximum" value for a multi-select field for each ticket?
Exibir comentário · Publicado 07 de jan. de 2021 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários
Ben Fulton comentou,
Regarding bulk update of existing users, I think we can muddle through by using bulk export to get the list and then perform a bulk update. However, bulk verification does not solve our email verification problem. What we are looking for there is a way to simply skip the verification process for each user with one of our internal domains *as they are created*, rather than after the fact in bulk.
Exibir comentário · Publicado 04 de jan. de 2021 · Ben Fulton
0
Seguidores
0
Votos
0
Comentários