Basics:Recipients (reply to all)

From Cerberus Helpdesk Wiki

In progress, transitioning to 5.x, will not make sense.

If you’re brand new to Cerb, one of the first Helpdesk concepts you must become familiar with is the recipient (if you're coming from 4.x, recipient is the new term for requester). A recipient is anybody who wishes to be part of the ticket conversation, in other words they want to receive replies from the Helpdesk. So when a customer writes you a new e-mail, the Helpdesk assumes this person wants to get a reply and the message’s “from” address becomes a ticket recipient. Thus, when you click reply the original sender will be listed in the “To:” field as a recipient.

Most of the time you don’t need to worry about the actual address in the recipient field. Your workers simply reply back to any new messages and the customer gets the response. However, there are time when you may need to change up the recipients a bit by adding or dropping addresses off the recipients list. Reasons include everything from a client’s supervisor wanting a copy of the follow-ups, to replying to a different contact in the same company after both wrote you separately requesting the same information.

Add (or delete) recipients

To change the recipients at any time, click the '(edit)' link next to the current recipients.

To add contacts there's a manual entry box where you can separate each address with a comma, otherwise click the big "+" button. This will open a second window called an "address chooser", sort of like a mini-"address book" to locate any contacts you have in the system already.

Similar to the other "choosers" you can use the address search to pinpoint e-mail addresses by domain, organization, or first and last name (Filter Presets?). Once you select your addresses, save changes, and then save changes again in the original window.

Changes CAN be made per-reply

Emphasis on the word "can". This is important because the 5.x behavior is a complete 180 from how recipients worked in Cerb4. In fact the old version of this section in the doc used to be called Changes are NOT per-reply, and what we meant by that was any changes you made to the recipients list would affect each reply going forward until you switched it back. In other words, you could not make a "one-time" change of the recipients list that would only affect the reply you were composing; there was no independent "To:" field to say I want this reply to only go to customer@example.com but leave original@example.com as the recipient.

This whole system has flipped from the bottom up, because now there IS an independent "To:" field to give you some control over each reply. When you start a reply the "To:" field pre-fills to whoever is on the recipients list, but it's plaintext now and can be overwritten and changed to anything you want. Whomever you write this reply to does NOT become a recipient automatically, and the next time you start a reply the same recipients list will pre-fill the "To:" field again.

Automatically: Reply to All

As you can tell my earlier example was very simplified, with the assumption that your clients sent an e-mail directly to your Helpdesk only. This scenario of course creates one recipient on the ticket (kevin.clark@cerberusdemo.com), nothing too complicated. Now if the customer puts other people in the “To:” or “Cc:” field, or even includes the Helpdesk on the “Cc:” and not the “To:” field, does this create multiple recipients?

Normally no. By default Cerb only replies back to the sender, anyone else the e-mail was addressed to originally has to be manually added to the ticket recipients list. However there is a reply to all option which will in fact create multiple recipients, adding everyone originally addressed in the "To:" or "Cc:" fields. All the configuration is done inside the ‘helpdesk setup’, ‘Mail Setup’ tab; in the Incoming Mail Preferences section checkmark ‘Reply to All’.

• To be clear this feature does NOT create a dedicated "Reply to All" button under each ticket. All that will happen is every valid incoming address will be added to the recipients list, and that set will pre-fill the "To:" field. Just like before you can override them per reply if you wish.

The new global exclude list

Notice there was an additional text box below the "Reply to All" setting; what separates our feature from traditional e-mail clients is you can automatically exclude certain recipients of your choosing. In the "Always Exclude These Recipients" box add any addresses you don't want receiving replies. Similar to other places in the Helpdesk that ask for an address, you can use use wildcards (stars *) to match any domains or e-mail names.

One very important difference from previous versions that we have to clarify before wrapping up. The 4.x "exclusion list" was sort of a soft ban; if one of the addresses wrote in a ticket of their own where they were the only possible recipient -- no "reply to all" or nobody extra in the "To:" or "Cc:" -- the ticket would make them the sole recipient. In practice the ban only applied to "reply to all" situations where there was multiple recipients at play, it would not allow a ticket to go without a recipient.

In 5.x it no longer works like this. An address on that list will be forever blocked, even if it results in a ticket with zero recipients. You can finally take the "ALWAYS exclude these recipients" box at face value -- it's a global ban. It doesn't matter if you have "reply to all" turned on, it doesn't matter if you try to add this address back in manually inside the ticket, it won't work.

Notice the red warning and the "Add to Recipients" button that replaced our 'Reply' button. In theory deleting all the recipients yourself from the ticket would have this effect but it's easy to recover from. If you wanted to add back the addresses from a specific message, you'd click the 'Add to Recipients' button and you're back to normal. But what happened in our example is we tried to add back a blocked recipient -- the only one the Helpdesk can automatically fetch through the senders on the message (remember we only have one message from one sender, so 'Add to Recipients' has nothing to draw from). Under this new system the Helpdesk will continue rejecting the address in several ways.

• Once you click 'Add to Recipients' the button will disappear, and not return to Reply; if you refresh the page the Add to Recipients button would reappear, click it, rinse & repeat.

• Because the Reply button is effectively blocked, the reply interface will never appear. This means you can not bring up the "To:" field to put in your own recipients.

• The same restrictions are put on manual overrides as well. Clicking the '(edit)' link next to your where your recipients list would normally be (it should read "nobody" right now) will also not work. Once you enter the banned address by hand and save, the page will refresh to nobody.

All this is not to say you're trapped in a corner. You can simply use the '(edit)' interface to add an address that's not on the exclude list, or you can have your administrator go back to the 'Mail Setup' configuration page and remove the blocked addresses. Nothing in the recipients system is permanent to the point you can't recover.

Why block recipients?

Believe it or not, this extra restrictive behavior is probably a good thing for locking your Helpdesk down. As an administrator it's important to overrule any attempts by your staff to reply to blocked recipients, whether it's intentional or not. For business-minded environments it can be a matter of strict confidentiality, carefully monitoring who receives replies may be valuable. Even if you don't need to be that strict, it has other practical applications as well, such as stopping your replies to automated senders (do-not-reply@example.com).

Other ways to ban contacts

If you're interested in blocking contacts beyond what the exclude list is capable of, there are several other Helpdesk features worth looking into. The following options deal more with blacklisting addresses than simply excluding them from outgoing replies, so feel free to enable a combination of all three for additional address restrictions.

• Each address in the Helpdesk has its own "Is Banned" field. If you set it to yes, this contact's new tickets will be rejected before they're parsed into the system. You can still reply back to existing tickets, which is why you may want to combine "Is Banned" with "Always exclude these recipients". "Is Banned" also prevents that address from registering or logging into the Support Center.

• Mail Filtering is the most flexible option on the table, but it may be overkill or require too much fine-tuning to get the desired results. The filtering system uses the same criteria interface you find in Mail Routing and Inbox Routing, so there's quite a few different types of filters you can create. Just like the exclude list you can go with the simple address match and use wildcards (banme@* or *@example.com) to capture more than one specific address. Unlike the other two options you have a couple choices on how little or how much you block -- you have a choice here to block all new tickets from this contact, reject replies only, or both. There's also a couple of ways how to "reject" that mail too; you can blackhole it, redirect it to an outside e-mail address, or bounce it back to the sender.