Mail Rules

From Cerberus Helpdesk Wiki

Cerb4 can be a great way to filter and sort your mail automatically, just don’t expect it to work out of the box. To get things up and running, you need to configure three levels of filters that all incoming mail must pass through. Thankfully each filter shares a very similar interface with similar criteria, so all you need to worry about is learning how to use each one's unique actions together to get your desired results.

If three filters are too much to configure up front, remember all of these tools are optional; still keep a look out for any patterns or trends you can base new filters around. The ultimate goal here is to allow Cerb4 to organize mail on its own, even if this requires you to constantly tweak the rules over and over. By the time your mail gets through the gauntlet, unwanted mail will be blocked and the rest will be dropped off into groups & buckets as new tickets.

In the meantime if you want to just use the pre-parser to drop spam, and let the Helpdesk dump all your mail into the default Dispatch group -- you can. If you want to add mail routing to divvy up all your mail into different groups, and then let your workers sift through tickets by hand -- you can do that too.

Note this entire process is strictly to manage new mail, replies to existing tickets will not be re-evaluated by the mail rules.

[edit] Filter #1: Mail Filtering

Pre-Parser removes unwanted mail before it turns into tickets.

You can think of the first gate as a doorman, stopping mail without the proper credentials from entering into the Helpdesk. Mail that fits your criteria does not become a ticket, is not written to the database, and is effectively removed from Cerb4’s jurisdiction. The most obvious use for the pre-parser is as a “spam catcher”, when used properly you can blackhole (or drop) spam from being converted into a ticket, saving you the trouble of reporting it later. Other actions include redirecting the message to another e-mail address outside the scope of Cerb4, or bouncing the message back to the sender.

To configure the pre-parser click ‘helpdesk setup’, the ‘Mail Filtering’ tab.

Known spammers can be handled up front, if you know their addresses block them right away.

• Note this section can be expanded via plugin. An example was documented on the wiki, which allows you to copy the contents of e-mail headers into custom fields.

[edit] Filter #2: Mail Routing

Mail Parser collects all the remainder of the incoming mail and divides it between groups.

After you filtered out as much unwanted mail as possible, now you move on to the legitimate mail that is converted into actual tickets. The second gate, “mail parser”, is for routing mail into different group inboxes of your choosing. Any leftover mail will be placed in the default group listed (set at Dispatch on new installs). Just remember if you have a couple of rules and the first rule successfully routes the ticket, any other rules in this section will not get a chance to run.

Click over to the 'Mail Routing' tab to start distributing your mail. You can also set global ticket custom fields at this juncture.

Your administrator decides on mail routing to determine which groups get what mail.

• You'll notice at the top of your routing list a place to choose a default group for unrouted mail. On new installs this is set to the Dispatch group, but if you happen to delete Dispatch the toggle will change to something else. It's always recommended you go back and confirm the new group is set to what you want, and not inadvertently rejecting e-mails. We've put in precautions to stop it from defaulting to bounce (CHD-849), but double check just in case.

Most people would rather have full control through 'Mail Filtering' on which e-mail is actually bounced.

[edit] Filter #3: Inbox Routing

Group Inbox Filtering organizes each group’s mail like the group manager wants.

Finally your mail is in the Helpdesk in the form of tickets, has been pushed into groups (inboxes specifically), and are waiting to be handled as each team sees fit. With "inbox filtering”, you can do just about anything you want to these tickets: move them to a bucket, assign them to a worker, or set even more custom fields (global and/or group). You can even take advantage of sticky and stackable rules in each group when you need to create different workflows for similar tickets.

Now it's not recommended, but theoretically at this stage you could move a ticket a second time to either another group or even directly to another group's bucket. However by not doing it this way, you avoid any troubleshooting headaches where tickets mysteriously end up in a bucket without being properly filtered by the group. For example, if a ticket suddenly ends up in the Sales group's Orders bucket unexpectedly (no subject = new order*) and a worker didn't move it by hand, you'd have to look in the Audit Log or check each group's filters for misconfigured rules.

To configure the inbox filters click ‘group setup’, a group name, and the ‘Inbox Routing’ tab. Decide now what your group workflow will be.

Your group managers take over "administrative" duties with any mail that makes its way to the group.

• You can also manually run the group's filters by simply dropping tickets into its inbox. Use this feature to get back on track when unfiltered mail somehow slips through the system.

[edit] (-add filter-) shortcut

There is a second way to add Inbox Routing rules "on the fly" AND run the filter against a set of tickets at the same time. To try this feature out make sure you expose the 'Bucket' column in your ticket list. Ticket lists include places like Overview, Workflow, Search or even workspaces. Once you're done, any ticket that's contained in a group's inbox will show an '-add filter-' link in the column instead of a bucket name.

Remember you're still creating group-level rules, meaning the new filter is only run on tickets in that group (e.g. Sales). This isn't Mail Routing.

Click the link and an edit window similar to the one we've seen before will appear; the major difference is the inclusion of a headers area up top. This gives you some of the data contained in the ticket which you are free to copy and paste to create your new rule, for example, take the Subject and add a wildcard (*) into the 'Message' criteria.

From the selected ticket a sampling of the message headers displayed for your convenience.

Once you save your changes the rule will run against ALL tickets in the group's inbox, not necessarily just the tickets in your "customized" view. So if you were looking at a workspace that only showed tickets from today, the rule would disregard the creation date.

• If you check 'group setup', you should see your new filter in 'Inbox Routing'.

[edit] When to use Mail Routing or Inbox Routing

Now Mail Filtering is sort of the odd man out in this whole system, because you may not need it depending on how much unwanted mail you get and how you choose to handle it. For instance, some users concerned with quarantining spam before wiping it, should avoid using the pre-parser for spam management.

With that said, there are a couple more variables at play when deciding to use Mail Routing over Inbox Routing or vice versa. Just about every Helpdesk install can benefit from utilizing both of these in everyday production and it's important to use them the right way so they work together rather than against each other.

[edit] Company workflow (group inboxes) vs. Department workflow (buckets & assignments)

The whole idea here is to give groups more sway over their own workflow, so they can decide how to manage their tickets completely independent of each other. Mail Routing should be done by the helpdesk-level staff to get tickets to the right teams, while the group-level employees can further organize through Inbox Routing.

My buckets don't appear in the dropdown.

You see the spirit of this design in Mail Routing, where mail is pushed into each group’s INBOX. Observe how you can not specify buckets to bypass inbox. The Cerb4 workflow you often hear about is really a team of people (Helpdesk group) defining a consistent method of assigning tickets to the right workers with the right data, and placing them into the appropriate “work-focused” buckets through Inbox Routing.

[edit] Administrators vs. Group Managers

Control who is an Administrator and who is a Manager in the edit window. For Managers change the dropdown next to the corresponding group.

Mail Routing and Inbox Routing cater to a different worker-type in your Helpdesk. Administrators can (and should) be in control of ‘helpdesk setup’, while Group Managers should control their ‘group setup’. Since Mail Routing is a global helpdesk setting, this means an Admin is in charge. And because Inbox Routing is an individual group setting, this puts a Manager in charge. Note that Admins can always override a Manager and tweak ALL mail filters.

[edit] Global ticket fields vs. Group ticket fields

The Billing group's 'Ticket Fields' tab as opposed to the Helpdesk Setup 'Custom Fields' tab.

Ticket fields are used to hold any additional data about your tickets you want, and how you create them is totally up to you. You can set ticket fields at the Mail Routing and Inbox Routing levels, but even though you can set global ticket fields from both, you can only set group ticket fields in Inbox Routing. Each group can configure its own ticket fields which only it has access to, to hold onto whatever extra information they feel is important. Once again giving groups the chance to organize their mail the way they want to.

Adapted from a Cerb4 blog post and now updated to reflect 4.3 interface changes. Merged with blog post/wiki article blog post.