최근 검색
최근 검색 없음

Rafael Santos
가입한 날짜: 2022년 3월 10일
·
마지막 활동: 2024년 11월 18일
CRM Manager, Customer Service, at Uphold Inc
팔로잉
45
팔로워
5
총 활동 수
360
투표 수
50
플랜 수
232
활동 개요
배지
문서
게시물
커뮤니티 댓글
문서 댓글
활동 개요
님의 최근 활동 Rafael Santos
Rafael Santos님이 에 댓글을 입력함
Jhanel Ayson Using the Search API
GET /api/v2/search.json?filter[type]=ticket&query=custom_status_id:30708872699803
Important: The
query
strings in (…) must be URL encoded before use.
댓글 보기 · 2024년 11월 18일에 게시됨 · Rafael Santos
0
팔로워
2
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Zerviz Mejora continua The ticket attachment flow via API is described in this Developer documentation page:
댓글 보기 · 2024년 11월 12일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
The “New Look and feel for triggers” HTML Editor completely breaks mixing HTML with Liquid tags, as it wraps everything in paragraphs.
Please review ASAP. I've opened ticket #13088165
댓글 보기 · 2024년 11월 08일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Hey Ankita,
The Search API has a limitation, noted on its API Reference page: Zendesk API Reference - Search:
Note: It can take up to a few minutes for new tickets, users, and other resources to be indexed for search. If new resources don't appear in your search results, wait a few minutes and try again.
Hence searching for the record right after creating the ticket will sometimes lead to an empty result, as it may not be indexed yet.
You can, however, obtain the created ticket's requester_id
to get the respective user from the Show User endpoint.
My recommendation would actually be something different:
- First Creating or Updating the user with all their relevant properties and user fields updated.
- Then Creating the Ticket with their
id
on therequester_id
andsubmitter_id
properties, ensuring that any usertags
are be inherited by the ticket on creation, assuming you have that setting enabled.
댓글 보기 · 2024년 5월 20일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Hey Alisa,
That exactly already exists: Ticket save hook events
You can have a Zendesk Support app intercepting agent comments, have its content be sent to a backend app of yours and set to a waiting state, in which you can either periodically poll for a result, or wait for a notification, have the BE app validate language or whatever else you define, then finally submit the comment, submit the updated comment, or do nothing.
댓글 보기 · 2024년 5월 20일에 게시됨 · Rafael Santos
0
팔로워
1
투표
0
댓글
Rafael Santos님이 에 댓글을 입력함
Andy F. , I'd use the PUT /api/v2/tickets/{ticket_id}/tags
endpoint instead of PUT /api/v2/tickets/update_many
, as the latter creates a background job, which may be rate limited to 30 concurrent jobs for the entire instance.
You could use the Add Tags endpoint, as mentioned above, with a payload such as the following:
{
{%- assign randomizer = ticket.id | modulo: 2 -%}
{%- case randomizer -%}
{%- when 0 -%}
{%- assign randomTag = 'control' -%}
{%- when 1 -%}
{%- assign randomTag = 'experiment' -%}
{%- endcase -%}
"tags": ["{{ randomTag }}"]
}
As for your other question:
How would I use liquid markup in this JSON response to tell it not to fire if a ticket already has the control or experiment tag?
The following trigger conditions could help you exclude this from firing on follow-up tickets with the tags:
- Ticket Is Created
- Channel Is not Closed ticket
- Tags Contains non of the following: [ control, experiment ]

Of course, it'll depend on your specific use case. You could also try iterating over the {{ticket.tags}}
placeholder and use Liquid's contains
.
댓글 보기 · 2024년 4월 24일에 게시됨 · Rafael Santos
0
팔로워
2
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Apologies, but I really believe you haven't, though.
I mean enabling for the entire account, not for individual agents. We want to control when it happens instead of having the update drop randomly during the day.
댓글 보기 · 2024년 3월 26일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Amisha Sharma, we understand it'll be enabled for the entire instance.
I'm just wary of such agent-impacting changes, such as the Redaction Suggestions EAP, which was enabled without notice while having a bug that impacted the agents' experience.
If enabling the feature could have a system-wide setting on Admin Center > Agent Tools > Agent Workspace, we'd be able to test in Sandbox, capture all relevant screenshots and screen recordings for our internal documentation, let the teams know of the change with some time in advance, then happily enable it, too.
댓글 보기 · 2024년 3월 26일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글
Rafael Santos님이 에 댓글을 입력함
Hey Amisha Sharma,
If signing-up, could it be made available with config disabled by default, so that we can control its status and respective change management internally?
Otherwise it could lead to disruption for any colleagues using the impacted instances.
댓글 보기 · 2024년 3월 25일에 게시됨 · Rafael Santos
0
팔로워
1
투표
0
댓글
Rafael Santos님이 에 댓글을 입력함
Hey team, could you please update the API Reference documentation to include Queues?
I guess it could be on Omnichannel, Ticketing, or Betas and EAPs.
FYI Jacquelyn Brewer, Barry Neary
List queues:
GET /api/v2/queues
Create queue:
POST /api/v2/queues
List queue definitions:
GET /api/v2/queues/definitions
Show queue:
GET /api/v2/queues/:queue_id
Update queue:
PUT /api/v2/queues/:queue_id
Delete queue:
DELETE /api/v2/queues/:queue_id
댓글 보기 · 2024년 3월 22일에 게시됨 · Rafael Santos
0
팔로워
0
투표 수
0
댓글