Basics:Mail Rules
From Cerberus Helpdesk Wiki
Contents |
As of Cerberus 5.4 this entire page is obsolete
Cerb5 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. By the time your mail gets through the gauntlet, unwanted mail will be blocked and the rest will be dropped off into groups & buckets. Thankfully each one shares a very similar interface, with similar criteria, so everything is fairly intuitive.
If three filters are too much to configure up front, remember all of these filtering tools are optional. But over time look for patterns and trends you can base new filters around to consistently keep your mail organized on its own. 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.
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 Cerb5’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 Cerb5, or bouncing the message back to the sender.
To configure the pre-parser click ‘helpdesk setup’, the ‘Mail Filtering’ tab.
- One thing unique to Mail Filtering is it works with customer replies and not just new messages (Criteria: Message "is a" reply). This means you can discard replies before they merge into the ticket, something you may want to consider if you have to contend with vacation responders re-opening closed tickets.
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.
- A wildcard * tells the system to allow any text in its place, giving you the ability to write simple pattern-based expressions. Check out the TO/CC caption: support@example.com, support@*, *@example.com. All three can represent the same e-mail address, and the latter two can match a ton of different combinations; support@* will pick up any domains where "support" is the lead-in, and *@example.com any address in the domain "example.com". Even when it's not explicitly stated just about every criteria accepts wildcards (including FROM and SUBJECT), so be careful not to read our interfaces too literally. With that said, FROM does not support comma-delimited addresses yet (see CHD-1470).
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, 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.
- 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.
(-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 ('customize') 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.
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.
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'.
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.
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.
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 Cerb5 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.
Administrators vs. Group Managers
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.
Global ticket fields vs. Group ticket fields
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.
