Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen
![Ben Fulton's Avatar](https://support.zendesk.com/system/photos/1900069666484/profile_image_1263169339250_10557657.jpg)
Ben Fulton
Beigetreten 16. Apr. 2021
·
Letzte Aktivität 04. Jan. 2024
Folge ich
0
Follower
0
Gesamtaktivitäten
29
Stimmen
0
Abonnements
15
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Ben Fulton
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 04. Jan. 2024 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 31. Aug. 2022 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 05. Mai 2022 · Ben Fulton
0
Follower
4
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 05. Jan. 2022 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 21. Juni 2021 · Ben Fulton
0
Follower
6
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 15. Juni 2021 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 14. Juni 2021 · Ben Fulton
0
Follower
2
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 11. Jan. 2021 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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?
Kommentar anzeigen · Gepostet 07. Jan. 2021 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare
Ben Fulton hat einen Kommentar hinterlassen
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.
Kommentar anzeigen · Gepostet 04. Jan. 2021 · Ben Fulton
0
Follower
0
Stimmen
0
Kommentare