Sticky and Stackable mail filters

From Cerberus Helpdesk Wiki

I'm going to break down rules, or filters, into three types: regular, sticky, and stackable. The first thing to note is there’s a natural progression between the filters: a regular rule can be promoted to sticky, and a sticky rule can be promoted to stackable. Also, two unique abilities are granted at each promotion: sticky rules gain the ability to be sorted manually, and stackable rules gain a second advantage with the ability to run more than one rule.

Contents 1 The Regular rules 2 The Sticky rules 3 The Stackable rules 4 How to create Sticky and Stackable rules 4.1 Chaining and the Inherent "Stack" 5 TEST CASE: Priority Clients and Phone Support 5.1 WITHOUT Sticky and Stackable filters 5.2 WITH Sticky and Stackable filters

[edit] The Regular rules

For regular rules (non-sticky and non-stackable), the run order is determined by match frequency so that the most likely hit is always checked first. As time goes on, the more common matches float to the top. Now the important distinction here is that regular rules obey the “one & done” principle. Once a criteria match is found, the actions you specified are triggered (e.g. assign to …), and everything stops, no more rules beyond that are checked. For performance purposes this is great because statistically speaking the system evaluates the most common rule first, and theoretically won’t have to keep evaluating each ticket after a successful match.

[edit] The Sticky rules

Unlike the regular rules, “Sticky” rules are sequenced based on the order YOU specify, and are run first before non-sticky rules. This means you can prioritize the rules however you want and guarantee ones of your choosing are checked first. Like non-sticky rules, these are also “one & done" unless they are promoted to stackable.

[edit] The Stackable rules

“Stackable” rules allow you to run multiple rules in succession and combine their results. So if the first rule that matches is stackable, the resulting actions are triggered, and the system continues down the stack looking for a second match. If there’s a second match, those rules’ actions are added to (or on top of) the first rules’ actions; and of course if that second rule is also stackable then it looks for the next rule, and so on and so forth. Remember stackable rules are also by definition "sticky" rules, which means they inherit the sorting ability.

[edit] How to create Sticky and Stackable rules

Go to ‘group setup’, the 'Inbox Routing' tab and create or edit one of your rules — you’ll see a “Sticky” checkbox below the ‘Rule Name’. After you enable “Sticky”, the “Stackable” checkbox will appear. If you ever need a reminder to what these filters actually do, both checkboxes are equipped with tooltips. Just hover your mouse over the names and you should get a nice summary of either option.

Once you save your changes, the sticky rules will be highlighted yellow alongside your existing rules, and if they’re stackable will also display "(Stackable)" next to the title. Notice the regular rules list the ‘Order’ column as ‘(auto)’, but a sticky rule replaces that with a numerical input box where you can specify your own order numbers.

In case you didn’t know, there are three places to create mail filtering rules. All of them let you create sticky rules but only “Inbox Routing” lets you make them stackable.

• helpdesk setup -> Mail Filtering
• helpdesk setup -> Mail Routing
• group setup -> Inbox Routing

The first two mail filtering types lend themselves to more one-off actions, such as bouncing e-mails or moving mail from Dispatch to another group, so the stackable option isn’t available. On the other hand combining “stackable” actions like ticket statuses, assignments, or custom fields is more driven by individual group rules.

[edit] Chaining and the Inherent "Stack"

A couple of little quirks I want to clear up:

Note that Mail Routing sort of "inherently" uses the stackable filter concept for rules that set ticket custom fields in place of moving. In other words, if you create a "sticky" rule that flags a ticket with a priority field and the following rule is set to actually move the ticket to a Support group. Both rules will run before the Mail Routing chain will cease.

Now for clarification, the workflow chain doesn't necessarily stop at that point. This is because each separate area runs "independently" with its own mail rule chains. So when I say that execution stops at Mail Routing OR if the matching rule isn't stackable, it's really only interrupted for that specific section. Once the ticket is passed from Mail Routing to Inbox Routing, "one & done" simply completes that area's chain. As soon as the ticket is passed to another group then the new group's rules can go through the motions.

[edit] TEST CASE: Priority Clients and Phone Support

So now comes the important part, when or why should you use sticky and/or stackable filters. The traditional filters can do a lot by themselves already, and are probably good enough for most people. However there are some limitations you’ll find if you try and do anything more complex. Sticky and stackable filters directly address these shortcomings, opening up the door to more unique workflows.

To showcase what these special filters can do, compared to the regular ones, I’m going to walk you through an example test case and a sample rule set from both angles. You’ll see why the basic filters makes this design cumbersome to implement and possibly unreliable.

Let’s try to create a set of ‘Support’ group rules to flag priority clients with a 48 hour response target AND separate tickets that need a phone call follow-up. We can break this down into four types of incoming tickets, which we’ll call scenarios #1-4.

1. Priority client who wants to be called within 48 hours,
2. Priority client who needs to be e-mailed within 48 hours,
3. Non-Priority client who wants to be called,
4. And Non-Priority client who needs to be e-mailed (this is pretty much everyone else).

[edit] WITHOUT Sticky and Stackable filters

If you’ve never used sticky and stackable filters, one possible configuration you might think of would be a simple four rule layout where each rule directly corresponds to a scenario. By the end of the mail rules, a priority ticket gets ‘+48 hours’ attached to the “Response By” date field AND is either moved to the ‘Phone Support’ bucket or defaulted to the ‘E-mail Support’ bucket.

There are two important things to notice in the screenshot:

• First, rule #2’s criteria is a subset of #1’s, both share the “from: address” criteria (priority@example.com), while #1 adds the “phone call” criteria on top of that which scans the message body for “call me”-like text.
• Secondly, that rule #2 has floated to the top above #1 because it has more matches (12 vs. 7).

The general problem with this design is the basic overlap of criteria between filters. Since the regular rules auto-prioritize based on matches, if any rule with a subset of criteria starts to become dominant due to an influx of tickets that only match that rule, it will become the first rule checked. Unfortunately these matches are “one & done”, and at this point any tickets matching the larger set of criteria will get picked up by the simpler rule first, ignoring the more complex rule completely.

So in our example the conflict is easy to see between rule #1 and rule #2. If you get too many tickets of type #2, where the ticket is from ‘priority@example.com’ and does NOT request to be called by telephone, the first rule (with the phone criteria) will not match and the second rule will, causing #2 to surge to the top of the list. Then the next time you get a ticket of type #1, it will be “preemptively” caught by rule #2 because of the ‘from’ criteria match and the mail rule checker will stop execution. This means rule #1, the “better match”, which also checks if priority clients are asking for assistance by telephone, will never be evaluated and thus the ticket will NOT be flagged for phone support.

Here is a sample ticket that SHOULD have been picked up by rule #1, but WAS picked up by rule #2 instead. Observe it was pushed into ‘E-mail Support’ when it was clearly requesting a call back.

[edit] WITH Sticky and Stackable filters

Now here’s the good news! The inherent problem with overlapped criteria can be removed with three rules — two stickies, one of them stackable.

1. Check for Priority clients only, if “yes” set a response time of 48 hours. (Sticky/Stackable)
2. Now check if client wants to be called, if “yes” move to ‘Phone Support’, (Sticky)
3. Otherwise move to ‘E-mail Support’.

Remember, sticky filters immediately removes the problem of auto-sorting and lets you force the new rule #1 to always be checked first, no matter what. You do a simple ‘from’ criteria check and set the 48 hour response time upfront for priority clients. By setting the rule to stackable, you then let the system continue and check sticky rule #2 for phone call requests. If the ticket matches both scenarios the actions will be “combined” — the ticket will be added to “Phone Support” along with the 48 hours response time. Since rule #2 was not stackable, you’re done as the system will exit on its own. Otherwise, there was no phone call requested and the second rule is “skipped”. The last rule fires automatically, as there is no criteria to check, and moves the ticket to “E-mail Support”.

(And of course if the ticket matched the fourth scenario and was NOT a priority client and NOT asking for phone assistance, the first two rules would not match and the last rule would become the default action.)

---

Adapted from a Cerb4 blog post.