Recent searches
No recent searches
Feature Request: Make "Secure Attachments" a per-attachment setting instead of a global setting
Posted Dec 18, 2023
Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)
I want to be able to send some attachments as "secure" and others normally. Currently, it is an all-or-nothing global setting. This affects agents and customers. Agents cannot attach non-sensitive helpful inline screenshots, for example. Also, customers must sign in unnecessarily for non-sensitive attachments. Customers also miss attachments often because they are not embedded into the email. However, we still need secure attachments as we do occasionally send sensitive data.
What problem do you see this solving? (1-2 sentences)
Agents would be able to send inline screenshots, customer experience would be streamlined when attachments are not sensitive.
When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)
This likely happens at least once per day across our team. We would like to be able to send a screenshot or a non-sensitive attachment but don't bother because the customer would need to sign in to view it. There's a 50/50 chance the customer even sees the attachment link and a further 50/50 chance the customer even knows how to get into their account.
Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)
Occasionally we will just email the customer directly outside of Zendesk.
What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)
As an agent, when I add an attachment, Zendesk should ask me if it should be sent securely or not. The global setting should be kept if Zendesk customers still want to enforce secure attachments. However, users with the setting off should be given the option to send attachments securely.
6
5 comments
Joey
Great request.
Ideally it would relate the secure attachments setting to private groups, in our instance those groups deal with sensitive information that should always be secured. But our main support teams deal with non-secure screenshots and images.
1
Emily Reidy
Thank you for taking the time to provide us with your feedback and for using the product feedback template. This has been logged for our Product team to review. For others who may be interested in this feature request, please add your support by upvoting this post and/or adding your use case to the comments below. Thank you again!
0
Chika Chima
Hi Kaleb Micklatcher
I am interested to learn more about your feature request. Very detailed btw. Would you be interested to having a call in the upcoming weeks?
Thanks!
0
Kaleb Micklatcher
Chika Chima Sure!
0
Florian Bartl
Our end-users are big, highly security-aware companies in Europe who exchange confidential data with our support team. Data confidentiality, data protection and strict IT-security rules play a huge role in support interactions.
Not-secure attachments are absolutely inacceptable to these end-users. This especially refers to incoming attachments (=attachments that our end-users transfer to us, e.g. upload in the Zendesk Help Center). Therefore it is a MUST for us, to use the secure attachments feature.
The problem is: At the same time, we frequently need to use “inline images” (e.g. screenshots that are placed within the text flow) in public comments. At the moment “inline images” do not work when the secure attachments feature is enabled.
This feature request would ease the problem: Per default “secure attachments” must be active, especially for incoming attachments. But for selected public messages, we could deactivate “secure attachments” in order to use (non confidential) inline images in the text flow.
A different solution would be: Allow “inline images”, even with the “secure attachments”-feature activated. However, that would be a different feature request.
1