Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen

Bryan Haeussler
Beigetreten 22. Okt. 2021
·
Letzte Aktivität 06. Jan. 2025
Folge ich
0
Follower
0
Gesamtaktivitäten
48
Stimmen
17
Abonnements
20
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Bryan Haeussler
Bryan Haeussler hat einen Kommentar hinterlassen
Am I correct in understanding that we can have multiple forms of set up going in parallel (e.g. some emails on two-way connectors, some emails on one-way connectors, some emails on ‘standard’ non-connector configs)?
We are interested in going to SMTP connectors because we want more control over the out-bound mail, but we have dozens of addresses and hundreds of open tickets. There are complex requirements around our ticket groupings (it is critical that the ‘from’ address not be incorrect on an outbound email). It seems like doing a progressive launch would be logistically easier than trying to move every email address at once.
Kommentar anzeigen · Gepostet 06. Jan. 2025 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Is it possible to fully prevent the automatic addition of followers? There is a privacy concern with a ticket moving through a normal email system and eventually getting to an agent who was not involved in the original ticket but then forwards it back into Zendesk, resulting in a public reply on the original ticket since their forwarding automatically makes them a follower. In most cases you may want an agent's emails to the system to be public, but in this case they have no idea they are going to contribute a ‘third party’ response to the existing ticket.
Kommentar anzeigen · Gepostet 17. Mai 2024 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
I am hoping someone can clarify the inbound limit on attachments on emails? I receive Remote server returned '550 5.7.0 Local Policy Violation - MaxSize Violation for an email with an attachment of 38MB, but I do not for one of 23MB.
I believe this article refers to the outbound limits?
Kommentar anzeigen · Gepostet 17. Jan. 2024 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Not sure if this will be helpful for your case or not but I have been doing this successfully by only passing the string 'remote_photo_url' instead of doing anything with the photo object itself e.g.
{
"user": {
"remote_photo_url": "https://example.com/example/path/image.png"
}
}
The response body will not include the photo, but a subsequent GET will show the details-- I assume collecting the data from the url specified and writing the photo object, etc. is done asynchronously.
Kommentar anzeigen · Gepostet 21. Dez. 2023 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Is it possible to determine which phone number was sent an SMS message within Support or through the API?
Kommentar anzeigen · Gepostet 10. Jan. 2023 · Bryan Haeussler
0
Follower
1
Stimme
0
Kommentare
Bryan Haeussler hat einen Post erstellt
Managing end users can be complicated if you want to purge stale users on a rolling basis. The ticket history can be valuable particularly if the person only periodically reaches out. There is not a good way to do this on a time basis-- e.g. purge users not active in the last 12 mo. 'Last login' does not capture ticket exchanges, or involvement in side conversations. It would be ideal if the system could reflect an updated timestamp anytime someone sends an email, receives an email, is sent a side conversation email, sends a reply to a side conversation email, engages in a chat, interacts with the bot, or logs into the system.
Gepostet 30. Nov. 2022 · Bryan Haeussler
1
Follower
2
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Any chance of getting an update on this one Gaurav Parbat? Doesn't seem likely it made it into the 2022 roadmap but maybe is still being considered?
Just want to add another comment in support of some feature to at least allow editing TAGS from the API or some other developer accessible portal. It is really painful to try and clean up custom fields supported by tags and find that you cannot really remove anything without a huge impact to your legacy data/searching/views. For example, "Cameras" in the custom field 'category' is changed from "camera" to "cameras" at the tag level and now the entire history of that field becomes largely inaccessible to 99% of users. To find old tickets with the same category (the end users only ever saw 'Cameras' as the category) they need to know it was at one point ID'd as 'camera.' There is no real way to know this unless you document it outside the system.
I am sure there are performance considerations but opening it up through the standard ticket/bulk ticket APIs would at least limit how many and how often users could do the updates while also giving them the ability to queue up fixes.
P.S. if you are reading this and having issues with Explore I suggest creating a custom attribute and making use of 'IF ELSE' statements to wrap your old tags into their 'new' versions.
Kommentar anzeigen · Bearbeitet 01. Dez. 2022 · Bryan Haeussler
0
Follower
5
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Is there any plan in the future to allow some level of customization of the live data queries?
To give an example of an element you might want to report on in addition to just group: 'unassigned' vs. 'assigned' tickets, since this helps to understand the flow of the backlog with a bit more precision (e.g. a number of open but assigned tickets are likely to resolve more quickly than a lot of open unassigned tickets).
Kommentar anzeigen · Gepostet 18. März 2022 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Is there any plan to allow customization of the pop-up window that displays the side conversation - ticket fields? Specifically, adding custom fields, or additional 'default' fields?
We run into the issue that these tickets cannot be marked up with any ticket field values, where often the agent initiating them might know them up front, and they would be relevant for workflows. This leads to cases where a generic ticket enters a group's feed and may not get the right attention. Of course, the agent creating it can take the shortcut to the ticket, but there is on the one hand cases where they are not in the group they assign the new ticket to and other cases where it is just a needless inconvenience.
Kommentar anzeigen · Gepostet 17. Dez. 2021 · Bryan Haeussler
0
Follower
2
Stimmen
0
Kommentare
Bryan Haeussler hat einen Kommentar hinterlassen
Any plans to add text coloring to the standard rich text editor for Support?
Kommentar anzeigen · Bearbeitet 02. Dez. 2021 · Bryan Haeussler
0
Follower
0
Stimmen
0
Kommentare