Vor Kurzem aufgerufene Suchen
Keine vor kurzem aufgerufene Suchen

Sebastian Bornemann
Beigetreten 16. Okt. 2021
·
Letzte Aktivität 27. Dez. 2023
Folge ich
0
Follower
0
Gesamtaktivitäten
21
Stimmen
5
Abonnements
4
AKTIVITÄTSÜBERSICHT
BADGES
BEITRÄGE
POSTS
COMMUNITY-KOMMENTARE
BEITRAGSKOMMENTARE
AKTIVITÄTSÜBERSICHT
Neueste Aktivität von Sebastian Bornemann
Sebastian Bornemann hat einen Kommentar hinterlassen
Works perfectly via webhook instead of HTTP target. :)
Kommentar anzeigen · Gepostet 01. Apr. 2022 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Neil Weldon What exactly is worked on, what can we expect? "Endless rerouting" or just the visible phone numbers?
Kommentar anzeigen · Gepostet 29. März 2022 · Sebastian Bornemann
0
Follower
2
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Neil Weldon "In a circumstance where an agent steps away without changing their state it could cause a call to be retried to that agent again and again if they are the only one available." Yes, that is no problem. If no one can answer, the customer should have the option to just wait it out, until that one single agent returns from the loo.
"Simply retrying agents with a call does not work in all circumstances, especially for smaller teams." Let your customers decide that.
Zendesk does lack basic functionality here. We have a presales team of around 3 people, of which sometimes one can be on vacation and one can be ill or just logged out to do customs work or other sit in a meeting. You have a 1-2 person team now. The likelyhood of a customer having to wait for one agent to finish a call is very high, and not having a simple endless loop is a massive impact on usability!
And no, we DON'T want to offer callbacks! We use the wait time as "filter", so unimportant calls might be reduced in times of high loads automatically, instead of each customer making us more work with less own effort.
This feature should be unbelievably easy to implement. It's stupidly simple. How can that be so difficult??? Just ignore the "agent has already missed the call" counter if a specific setting is applied, and there you go.
Kommentar anzeigen · Gepostet 28. Jan. 2022 · Sebastian Bornemann
0
Follower
5
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi, we want to use talk starting in the next one to two weeks.
One problem, though: For tests, we have uploaded an 8 minute wait greeting (music with some spoken lines every few minutes).
When I call and choose the agent group via IVR, I hear the waiting greeting. Two agents are active in the group. First agent doesn't respond, second agent doesn't respond, and after that minute of waiting, the waiting greeting is cut off and the voicemail inactive greeting plays, and the call ends.
We want to circle that call around and try the agents again and again instead of ending the call when each one hasn't answered the first time. How do we do that?
Kommentar anzeigen · Gepostet 14. Jan. 2022 · Sebastian Bornemann
0
Follower
1
Stimme
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi Brandon,
thank you for clarifying. Now it makes a lot more sense.
If I would use a target with the file name .../{{user.id}}.json, I should be able to write into that field, correct?
But can I reference the ticket field this way around? If the file name in the target influences the "visible" fields, the script wouldn't be able to look the ticket field up, since it doesn't know which ticket to look at, correct?
Can I point to two different instances to get both fields?
Kommentar anzeigen · Gepostet 13. Aug. 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi Brandon,
please allow me, after reading your links, to post the remaining specific questions:
- Why is "user_fields" never mentioned on the whole of the placeholders reference?
- Do I need to use "user_fields" or do I need to use "custom_fields", which IS mentioned there for using with custom user fields?
- Can anyone tell me for sure that this custom user field is writeable?
"Important: Remember to replace user with one of the user types shown above (for example, ticket.requester)." This contradicts your aforementioned "solution" and several of my tested snippets.
The correct script should be:
{
"ticket": {
"requester": {
"custom_fields": [{
"key": "kundennummer", "value": "{{ticket.ticket_field_********3817}}"
}]
}
}
}
The exact script "structure" works the other way around, but calling the field by it's ID, not it's key. For this field, I have no ID mentioned anywhere.
This doesn't work, though. I switched to "basic" password authentification yesterday, and the API error now reads:
{ "error": "RecordNotFound", "description": "Not found" }
Which tells me what? I guess, that this field cannot be found using the "key"? But I don't have any other value to point to it.
I also found this thread: https://develop.zendesk.com/hc/en-us/community/posts/360001646788-End-Users-API-is-always-responding-with-404-RecordNotFound
It seems that the path for the target is wrong. But I never received any answer to my several questions regarding target paths. Is there any documentation?
I assume, the correct path would be: .../users/{{id}}.json
Before, the target path was: .../tickets/{{ticket.requester.id}}.json
Kommentar anzeigen · Gepostet 03. Aug. 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi,
this is the error:
Anfrage
PUT /api/v2/tickets/384518815337.json HTTP/1.1 | |
Authorization | Basic aW5mb0B2b2x0dXMuZGUvdG9rZW46 |
User-Agent | Zendesk Target |
Content-Type | application/json; charset=utf-8 |
Accept-Encoding | gzip;q=1.0,deflate;q=0.6,identity;q=0.3 |
Accept | */* |
Connection | close |
Host | xxxxxx.zendesk.com |
Content-Length | 67 |
{ "user": { "user_fields": { "kundennummer": "12345" } } }
Antwort
HTTP/1.1 401 Unauthorized | |
Date | Mon, 02 Aug 2021 12:46:04 GMT |
Content-Type | application/json; charset=UTF-8 |
Content-Length | 37 |
Connection | close |
WWW-Authenticate | Basic realm="Web Password" |
Strict-Transport-Security | max-age=31536000; |
Cache-Control | no-cache |
X-Zendesk-Origin-Server | classic-app-server-65cbc7b6cf-84bbh |
X-Request-Id | 67876829f95460f1-DUB |
X-Runtime | 0.868412 |
X-Zendesk-Zorg | yes |
X-Request-ID | 67876829f95460f1-DUB |
CF-Cache-Status | DYNAMIC |
Expect-CT | max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" |
Report-To | {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=ga6FsURew2p%2FkNw1XEyd2d%2BA6pkGDqW3o%2BG4XqXcqZ12MTI3SPGOragbg9l9j3Kwj7EKxN3giThj8RmKBil3fr6%2Fo999UyfVu%2BwRyRZXqeFMjrKFW0c7AyhDXC0fqSUdykDXYg%3D%3D"}],"group":"cf-nel","max_age":604800} |
NEL | {"report_to":"cf-nel","max_age":604800} |
Server | cloudflare |
CF-RAY | 67876829f95460f1-DUB |
{ "error": "Couldn't authenticate you" }
Authentification is the same as in the working script.
The erroneous script file is called {{ticket.requester.id}}.json whereas the working one is called {{ticket.id}}.json (but works the wrong direction.
Is there any relevance to these variables??? Also, is there any (?!) documentation about the file naming and variable structure regarding my problem? I didn't find anything specific and have no way to get deeper knowledge about this topic by myself.
Kommentar anzeigen · Gepostet 02. Aug. 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi Brandon,
this is unfortunately also no solution. It doesn't work.
Also, my question from above, if the outcome is affected by the file name of the json file (different variables used), hasn't been answered. Which target should I use?
I tried both targets with this code in the trigger:
{
"user": {
"user_fields": {
"kundennummer": "{{ticket.ticket_field_360015443817}}"
}
}
}
No luck, nothing syncs in this direction.
The comma in your script doesn't validate, by the way, I assume it is wrong there.
Kommentar anzeigen · Gepostet 02. Aug. 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi,
I doubt this will work since the agents should be able to write this field and read from it, too.
What about using the user "details" field, how would you write the script then? I seem to fail understanding how the fields have to be accessed.
Also, does the "file name" for the http target have any impact on the outcome?
(edit: Of course, in the long run, we will want to sync to our ERP system, but this is not possible at the moment.)
Kommentar anzeigen · Gepostet 26. Juli 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare
Sebastian Bornemann hat einen Kommentar hinterlassen
Hi, doesn't work either. But it underlines the first { bracket if I spare the ".
Kommentar anzeigen · Gepostet 25. Juli 2021 · Sebastian Bornemann
0
Follower
0
Stimmen
0
Kommentare