Add BCC field for ticket answers

Feature requests
1

Hello Community,

if you reply in Zammad, you have the option of adding additional recipients to CC. This feature is great.

As in all email clients, BCC would be desirable.

Are there any plans for this? We already have a few requests for this.

20 Likes
2

I am asking for this feature as well.
And I am aware that this request was always rejected in the past.

Therefore I’d like to share two use cases with you to explain why this feature is important to me.

Major Incident
During a major incident, a group of users need to be informed on a regular base that e.g. a service degradation is currently ongoing. Therefore I’d like to send out this information to the user community, without sharing their email identities in the to or cc field.

Change Management
A change is required and I have created manually a change ticket for tracking and communication purposes. Because the user community of the system must be informed about the change, e.g. because a change requires a planned outage, I’d like to send an email to them via the *bcc field, because I must not share their email identities in the to or cc field. And sending individual email to each person is not an alternative.

I hope I could make clear, why bcc is important to me and I am happy to discuss this further.

Best Tilmann

9 Likes
3

I’d like to add another usecase:

Whenever communicating via email with more than one external recipient or with a mix of external and internal recipients GDPR requires everyones consent to showing names resp. email-adresses to the other recipients. Using the ‘bcc’ field is the only realsitic way of writing to more than one recipient and fulfilling the requirements of GDPR.

So PLEASE add this feature - the sooner the better :slight_smile:

4

Hi @MaxG, @mark_hepster and @Tilmann-Glaeser ,

In general Zammad follows several Open-Source principles. One of which is transparency. BCC collides with that concept, as there are no “secrets” in Zammad.

There might be a misunderstanding: Zammad is an Open-Source Helpdesk Ticket System for multi channel communication. It’s not an email client.

How about about an e-mail list with hidden recipients as a customer in a ticket? service-app-status@blubb.bla with x recipients.

Best regards,
De Long

5

In general, we already have a story, but it currently has no priority.

2 Likes
6

@Dr4gon

that is some kind of “philosophic”.
i agree, that “OpenSource” should not contain any secrets within Code and functionality. That means, nothing that is hidden to the user.
But “Bcc” is not hidden to the user. It is an obvious and comprehensible functionality.
To my opinion hiding recipients’ email adresses (e.g. in order to defend recipients’ privacy) by using OpenSourceSoftware is like encrypting things by using OpenSourceSoftware.

Sounds like a workaround. But I do not understand how to do it.
Could you please write a short explanation?
Thanks a lot!

Mark

7

That depends on your mail server and has nothing to do with Zammad

8

Hey @mark_hepster ,

That depends on your e-mail server and hoster.

With most services, you can create an e-mail listing with e.g. colleague1@blubb.de, colleague2@blubb.de and some hidden (similiar to bcc) recipients hidden1@bla.de, hidden2@bla.de. The hidden ones are not visible in the mailing list. The other ones are. Then you can send to list@all.de - which in Zammad is a customer with an e-mail address - and all participants according to their visiblity privileges.

Best regards
De Long

9

Hi,
thank you for explaining.
I did search within Zammad - now it is clear.

Still I would prefer activating bcc within Zammad, but it could be a workaround. However, a really uncomfortable workaround.

10

I agree. Not being able to add BCC recipients on the fly and instead having to create a mailing list is not really feasible for most use cases.

  • agents need to have a list of the bcc mailing lists and know when to choose each one, the chance for errors can be high
  • if agents want to bcc a group that isn’t already covered in a bcc mailing list, they’ll need to have one created for them, or create it themselves. this lengthens the service time for tickets, especially if someone else has to create the bcc mailing list.

I disagree that bcc collides with open source principles. There are many practical reasons to have use bcc that aren’t meant to obfuscate. For example, there may be cases where customers should not have access to a recipient’s email address, for totally legitimate reasons.

It’s kind of unclear how “there are no secrets in Zammad” doesn’t apply to the ability for tickets to be sent to a group where agents outside the group aren’t able to view the tickets but it does apply for bcc usage.