The title says it all. Did you know those inbox mail rules you created in 'group setup' can be applied to existing tickets, and not just incoming mail? When you manually move a ticket to a different group's inbox with something like '(peek)', then that group's mail filters will be checked as if it were a brand new e-mail.

As expected any rule matches will trigger the resulting actions, such as setting a custom field or assigning the ticket to a worker. Note that this behavior is limited to group inboxes only, dropping a ticket to another group's bucket (e.g. 'receipts') will not run the mail rules.

I love this feature in particular because of the mixed reactions it can draw. Because of Cerb4's emphasis on group scope where each team determines their own workflow with things like mail filters, auto-responses, and buckets, this "move" behavior can be a point of contention over two sides of the same coin. Some people were begging for this functionality from the beginning, so they can retroactively filter tickets into each group's new workflow. Others find it annoying as it can interfere with their intended group's workflow at that moment, as tickets get rerouted or assigned without their "approval".

So an interesting scenario to put this to the test, is a “single group” worker who is writing to a new client and leaving the finished ticket for a second group they don’t have access to. The worker creates a new outgoing message with ‘Send Mail’, leaves the ‘From’ group as Dispatch (since he’s not a member of the Support group), and sets the ticket status to ‘Open’.

The message goes out to the client, your worker finds the ticket, and then moves it to the Support inbox. At this point the Support group’s mail filters take over and decide the rest of the workflow.

For better or worse, moving a message you’re composing on the fly by setting the ‘Next’ box’s “Would you like to move this conversation?”, does NOT run the mail filters. That’s a good tip to keep in mind if you want to bypass the mail rules.

Even though this is a very “cool trick” I wanted to share, the most important part of this article is to highlight three “odd quirks” to the behavior — small things that might catch users new to Cerb4 off guard. (Plus the next time I find someone who stumbles on the side effects and posts a question in the forums, I can just point them here.)

My ticket is not staying put where I left it

As most of you know, one of the possible mail filter actions you can configure is moving an incoming ticket to a different group. Normally this is not a point of confusion because you don’t “see it in action”. By the time you discover the ticket in your Helpdesk, it’s already been moved around and eventually come to rest in a specific target group. However, you may be confused the first time you decide to move a ticket back to the Dispatch group for a manager to evaluate. Only to find out after the filters ran and the screen refreshed, that the ticket ended up in the Support group.

Don’t worry. Yes, if a ticket gets routed back to a group more than once, it should stop right there and not cycle through again.

As far as I know, there isn’t a clean way to get around this functionality if you’re not a fan of the default behavior, especially if you use the Helpdesk like it was designed to work. If you don’t make all your workers members of the destination group, they won’t have access to that group’s individual buckets and must drop it off in their ‘inbox’, which of course can reroute the ticket depending on the filters.

If this becomes an annoyance, my best advice would be to leave a comment (or sticky note) when you move the ticket, telling whatever group receives it where the intended destination was.

I’m getting double Watcher notifications

Workers who deploy multiple watchers to update them on new tickets for several groups, will often find they get double e-mail notifications when the mail rules fire on an existing ticket that was moved. So for example, if you’re watching ‘incoming message’ events for the Dispatch group AND the Support group. You will get the initial e-mail notification when the message arrives in the Helpdesk via the Dispatch group, and a second notification after a worker read it and decided to pass the ticket on to the Support group.

For those paying close attention, you may wonder how this quirk reacts to the first quirk. When you move a ticket and it’s shifted to a couple of different groups by the mail filters, do you get a watcher notification for every group it passes through? The answer is no. According to the developers’ release notes for 4.2, the system has been designed “to only send the single notification at the end of a chain of auto-moves”.

Auto-responses don’t work the same way

After seeing this feature in action, a common follow-up question is do the new ticket auto-responses benefit from this same behavior. Say I want to use this system to escalate tickets manually by moving them to a higher-priority group. As part of the promotion, I also want to send the clients an auto-response that tells them “your ticket is now being handled by our Support team”.

Is this possible? Unfortunately no, but the feature request is currently an unscheduled wishlist item. Feel free to vote or leave your feedback on the CHD-1211 JIRA page.

There you have it! Three unique scenarios that can be baffling by the time you discover the joys of mail filtering. I’d recommend you give this article to all your new employees as part of their introduction to Cerb4. Good luck!

-joegeck@wgm