최근 검색
최근 검색 없음

Pedro Rodrigues
가입한 날짜: 2021년 10월 26일
·
마지막 활동: 2025년 2월 24일
Zendesk and CX consultant at Opservator.com 👋 Please note: I do not work for Zendesk, I just contribute as a Community Moderator.
팔로잉
1
팔로워
5
총 활동 수
883
투표 수
272
플랜 수
354
활동 개요
배지
문서
게시물
커뮤니티 댓글
문서 댓글
활동 개요
님의 최근 활동 Pedro Rodrigues
Pedro Rodrigues님이 에 게시물을 만듦
Overview
The Light Agent role in Zendesk has the following permission regarding “Customer Lists” (the page under /agent/user_filters):
"View user profile lists
Can search for users by name, email address, phone number, or organization. Doesn't affect their ability to add end users or edit their profiles."

Light Agents can therefore search and find end-users by name and email address. This permission is currently non-editable, which also means Administrators cannot restrict Light Agents from viewing customer lists entirely, or at least following the role's configured ticket access.
Problem
The inability to edit this permission means that Light Agents can access all end-user profiles in the account, regardless of their ticket access: while they may not be able to access a given user's tickets, they can access the user profile. This includes email addresses, phone numbers, and other sensitive information, creating a data governance challenge, especially for organizations that operate multiple brands and/or handle sensitive customer information.
Last time affected
This issue has been ongoing and affects anyone using the Light Agent role with a strict segmentation need regarding user access across Brands.
With the upcoming release of Department Spaces, there is an expectation that data access will be further segmented. However, this does not currently appear to cover the issue of Light Agents being able to access Customer Lists… It remains unclear if the feature will fully resolve this concern.
Current workaround
None. One can use a full agent seat in crucial scenarios, but this defeats the purpose of using the Light Agent role, so it isn't really a workaround.
Potential solution(s)
- Make the "View user profile lists" permission for Light Agents editable so that Admins can restrict access to customer lists
- Connect ticket access permissions to user profile access. I.e. if a Light Agent can only access tickets within their Groups, they can't access user profiles of requesters whose submitted tickets are outside these Groups
Thanks in advance for considering this request!
2025년 2월 04일에 게시됨 · Pedro Rodrigues
3
팔로워
3
투표 수
3
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Olá Luis Nagasako 👋 sim, é possível, pode ler sobre este assunto aqui e aqui, por exemplo.
Se já tem o Guide ativo, poderá visualizar o seu formulário atual em /hc/requests/new (por exemplo, https://exemplo.zendesk.com/hc/requests/new).
댓글 보기 · 2025년 1월 16일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hi Zendesk team, is it planned to have more detailed data in both Support (Views, business rules, etc) and Explore for this new CSAT experience? For example, the actual rating given as an integer. Use case: calculate CSAT ignoring the neutral value, and not considering it “negative”, when you have three or five rating options. Thanks!
댓글 보기 · 2025년 1월 07일에 게시됨 · Pedro Rodrigues
0
팔로워
1
투표
0
댓글
Pedro Rodrigues님이 에 게시물을 만듦
Overview
I would like Zendesk to restore the ability to clone triggers via the “clone trigger” URL while preserving the original trigger's elements (title, description, conditions, actions).
This impacts admins and anyone else whose role is allowed to manage business rules, and who rely on this functionality to streamline workflows, improve standard operating procedures (SOPs), etc.
Problem
If we clone a trigger and copy the resulting URL, as soon as we navigate to another page (e.g. to Automations) and then paste+Enter the clone trigger URL, it will show a blank trigger.
This means we can no longer use URLs to clone triggers directly, resulting in extra steps to locate and clone triggers manually. This slows down workflows, complicates documentation, and introduces (unnecessary) potential errors.
Last time affected
Today. This issue has been affecting our team since the original behavior changed (not sure when? Couple of weeks, more?).
It occurs every time we need to duplicate a trigger or I notice the SOP's clone trigger link now returns blank data Losing this functionality impacts our efficiency, especially when managing large numbers of triggers and documenting processes for training and consistency.
Current workaround
Besides having to update internal docs, we now have to navigate to the Triggers page, search for the relevant trigger, and manually clone it. ..This process is time-consuming and prone to errors.
Ideal solution
I would like Zendesk to revert to the previous behavior, where cloning triggers via URL links pre-filled the new trigger form with the original trigger’s details. This would simplify workflows, save time, and improve documentation practices.
Thanks in advance for considering this request.
2024년 12월 30일에 편집됨 · Pedro Rodrigues
1
팔로워
2
투표 수
1
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hi Arthur Venturina, by default the system-generated “Notify requester and CCs of comment update” (unless you edited it) will ignore any ticket statuses and notify the requester in both cases.
You do have Status-related trigger conditions, so you can set up a notification for cases where status changes to Pending or Solved and the current user is an agent (for ex).
Just a note:
- "Notify requester and CCs of comment update" only contains the conditions “Ticket is updated” and “Comment is public”, which means that whoever triggers a public comment will send a notification to the requester
- If you don't want to send a notification to the requester when they send a message (instead of the agent), that trigger must be edited. I'd therefore suggest adding a third condition “Current user is not end-user”, at the very least.
I highly recommend that new accounts check whatever business rules Zendesk creates by default and/or deactivate them altogether, because not touching them can be a spammy hassle - looking at you, “Notify all agents of received request” - if you start setting up the account and testing your ticket influx.
댓글 보기 · 2024년 10월 31일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hi Nizar Halaoui, regarding the file storage problem, we created the File Manager app, which deletes neither tickets nor users, just attachments. Users can search and sort by flie size, ticket creation date, for example.
Additionally, it is possible to download a CSV file of the search results table, which would allow you to identify the largest files.
Hope this helps!
댓글 보기 · 2024년 10월 31일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hi Chad Mitrado , I used your formula and it's working for me, for example, on the following table report:
- Metrics: Updates
- Columns: Ticket created - date
- Rows: First Assignee (your formula), Assignee name (to see who's currently assigned)
- Filters: I'm excluding NULL in the First Assignee attribute (because there's only one change/update we're interested in, which is the assignee_id field according to the formula's criteria)
The output allows me to see the number of tickets where each specific agent was the first assignee, as well as who's currently assigned. Checked multiple tickets specifically and everything looks correct.
Can you please share a screenshot or describe how you're visualizing your output?
댓글 보기 · 2024년 9월 21일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hey Zendesk team, just a suggestion: it would be great having an additional placeholder for autoreply.first_article_link. This it would allow us to edit the autoreply content in order to link to the article, especially in cases where we only send the first matching content (e.g. “It looks like this article may have the answer to your query: …”). Thanks!
댓글 보기 · 2024년 9월 13일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글
Pedro Rodrigues님이 에 댓글을 입력함
Hello Abdulqader Haddad, when we want to obtain “without a public reply from the Requester" we can assume two scenarios:
- Inbound tickets: there is always one requester comment at least, so I assume you need the number of tickets without any subsequent requester replies, which means we need to identify tickets submitted by end-users with a single requester comment
- Outbound tickets: in this case, we need to identify tickets submitted by agents where the number of end-user comments is zero
We can achieve this by creating your report and standard calculated metric under the “Updates history” dataset.
Your metric will look like this:
IF (ATTRIBUTE_FIX(D_COUNT(End-user comments), [Ticket ID]) = 1
AND [Submitter role] = "End-user")
OR (ATTRIBUTE_FIX(D_COUNT(End-user comments), [Ticket ID]) = 0
AND [Submitter role] != "End-user")
THEN [Update ticket ID]
ELSE NULL
ENDIF
This metric should be used with the COUNT or D_COUNT aggregators.
Example:

Our metric is validating 1.884 tickets in the table above, and we can see that two tickets were outbound (i.e. created by agents). After checking, these two outbound tickets don't have any end-user replies.
Hope this helps, happy Exploring!
댓글 보기 · 2024년 8월 16일에 게시됨 · Pedro Rodrigues
0
팔로워
0
투표 수
0
댓글