Hi, I have a question about an email workflow. I’m wondering if anyone can help me or tell me how you handle this scenario.
For example, an incoming email in the incident reports queue that has two people in cc generates a ticket. I reply to it, and the customer replies back, removing one of the CCs from the conversation since they shouldn’t be included from that point on. I don’t realize that they’ve been removed, and RTIR keeps them in the “People” field because it initially adds them automatically. From there, they can be sent to the next reply via script or manually because RTIR doesn’t check whether they should be removed or not.
How do you handle these situations? Any ideas?
Any suggestions are welcome.
Thank you very much!
Hi Alberto,
The question is whether you want the author of an e‑mail (customer or employee) to be able to add or remove people from the To: or CC: fields in the ticket. We do not want to allow that.
Remember: if the CC list remains in the reply, the CC recipients receive two e‑mails, one from the original author and another from RT.
We have two typical use cases:
- Single‑requestor case – only one customer is the requestor and no one else is involved. This works well.
- IT‑team case – a member of customer’s IT team is the requestor, with additional people in CC.
The user in this case knows our ticket system and replies only to the ticket instead of using “Reply‑All”. If they use “Reply‑All”, the CC recipients receive duplicate e‑mails, which they want to avoid.
After a brief learning period, customers are able to handle this themselves, and the process runs smoothly.
Therefore, at our company it is the ticket owner’s responsibility to manage the people assigned to the To: and CC: roles in RT. The only time the system automatically populates the To: and CC: fields from an incoming e‑mail is at ticket‑creation.
regards.
Hi rubberduck, thanks for the quick reply.
We use scripts to automate tickets and replies in specific cases, but setting up a separate queue and handling the ticket recipients as you suggest should solve the problem. Thank you very much!
This scrip does the opposite of what you want (It adds people to Cc: but only if it was added by someone already on the ticket belonging to the same domain.) This is to stop any random person from just adding themselves to any ticket, but also makes sure that if the customer adds someone at their organisation to the Cc:, RT will add them as a Cc to the ticket going forwards, so that any replies via email will also be copied to that person without us having to specifically add them.
Reversing the logic and then adding/removing a Cc: might be possible, but depends if you want it to apply for the current transaction only, or if it should update the ticket for all correspondence from that point.
It may work better if you use SquelchMailTo instead of DeleteWatcher so that the person remains on the ticket, but they don’t receive any emails, and it will be easier to add/unsquelch them back if someone starts to Cc: them in again.
Finally, after reviewing the code, I figured out how the DutyTeam works. I ran some tests in a development environment, and changing the script condition from “on correspond notify requestors and cc” to “RTIR Staff response notify requestors and cc”—and allowing only “staff” users within the DutyTeam group to respond to tickets—should do the trick.
In my case, I was unaware of these RTIR scripts, which for SOC environments like mine are exactly what I’m looking for.
The AddWatchersOnCorrespondDomains script would solve part of the problem, but we have clients who add and remove people in cc without any control, and teaching them how RT works isn’t an option right now. The solution in my case is through the DutyTeam logic, since it prevents duplicate responses and delegates the responsibility of checking who is on cc and who isn’t when replying to a customer ticket to the current ticket owner.
Thanks for the responses!
If you have any questions, feel free to ask.