Recherches récentes
Pas de recherche récente
![Ben Fulton's Avatar](https://support.zendesk.com/system/photos/1900069666484/profile_image_1263169339250_10557657.jpg)
Ben Fulton
Adhésion le 16 avr. 2021
·
Dernière activité le 04 janv. 2024
Suivis
0
Abonnés
0
Activité totale
29
Votes
0
Abonnements
15
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Ben Fulton
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 04 janv. 2024 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 31 août 2022 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 05 mai 2022 · Ben Fulton
0
Abonnés
4
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 05 janv. 2022 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 21 juin 2021 · Ben Fulton
0
Abonnés
6
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 15 juin 2021 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 14 juin 2021 · Ben Fulton
0
Abonnés
2
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 11 janv. 2021 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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?
Afficher le commentaire · Publication le 07 janv. 2021 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire
Ben Fulton a ajouté un commentaire,
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.
Afficher le commentaire · Publication le 04 janv. 2021 · Ben Fulton
0
Abonnés
0
Votes
0
Commentaire