Simplify and Reduce your Auto-Destination Rules using printf
Photo by @benchaccounting
When setting up your auto-destination rules, it’s easy to end up with rule bloat, sometimes due to no fault of your own.
Due to business requirements, you may end with a lot of rules, which end up making it difficult to manage all of them.
For example, we may have auto-dest (routing) rules that dispatch a case to a queue based on its case type and the country of the reporting site/contact.
- If the contact is in the USA, and it’s a Payroll case, send it to the USA_Payroll queue.
- If the contact is in the USA, and it’s a Benefits case, send it to the USA_Benefits queue.
- If the contact is in France, and it’s a Payroll case, send it to the France_Payroll queue.
- If the contact is in France, and it’s a Benefits case, send it to the France_Payroll queue.
- If the contact is in Mexico, and it’s a Payroll case, send it to the Mexico_Payroll queue.
- If the contact is in Mexico, and it’s a Benefits case, send it to the Mexico_Payroll queue.
- etc.
As the number of countries and case types grow, the number of auto-dest rules you have also grow. Before you know, you have this huge set of rules that becomes difficult to manage.
Plus, whenever you add a new case type, or start supporting another country, you need to keep updating these rules. Yuck.
printf
One way to help with this is to take advantage of the printf syntax that is supported within auto-dest rules.
This is definitely a more advanced syntax, but it can be super useful if you need it.
The printf syntax allows you to dynamically build a queue name based on values from one or more database columns.
It’s probably best illustrated with some examples.
Basic auto-dest rule syntax
Lets look at the basic syntax of an auto-dest rule.
The basic syntax is:
(condition) –> queue
So if the given condition is met, then send the case to that queue. Lets look at a specific example.
(title contains “Benefits” ) -> “Benefits”;
This rule will dispatch any cases whose case title contains the word Benefits to the Benefits queue.
The condition can be based on a related data object as well, so we can traverse relations using the relation:field syntax.
(calltype2gbst_elm:title contains “Benefits” ) -> “Benefits”;
This rule will dispatch any cases whose case type contains Benefits to the Benefits queue.
(calltype2gbst_elm is the relation from case to the gbst_elm table that represents the case type, and the title column on the gbst_elm table holds the actual case type value)
Now that we have a basic auto-dest rule, lets see how we can use the printf syntax.
Simple printf example
Given the following rule:
(objid > 0 ) -> “(“%s”, calltype2gbst_elm:title)”;
This says that for any case whose objid is greater than zero (which is all cases), dispatch it to the queue whose name is the same as the case type.
Notice the %s in that rule. That’s printf in action. The calltype2gbst_elm:title path will get resolved to a value, and the %s will be replaced by that value.
So, if it’s a Benefits case type, it will go to the Benefits queue. If it’s a Payroll case type, it will go the Payroll queue.
Multiple printf arguments
Rather than just substituting one value into the queue name, we can have as many as we want.
Going back to the example at the start of this post, lets say our queue names are a combination of country name and case type, with an underscore in between (such as USA_Benefits).
So we can use this rule:
(objid > 0 ) -> “(“%s_%s”,case_reporter2site:cust_primaddr2address:address2country:name, calltype2gbst_elm:title)”;
Notice that the queue name contains %s twice, with an underscore in between.
And we have two paths/fields: country name (case_reporter2site:cust_primaddr2address:address2country:name), and case type (calltype2gbst_elm:title)
So, if the country is USA, and the case type is Payroll then the queue will be USA_Payroll.
And if if the country is France, and the case type is Payroll then the queue will be France_Payroll.
Pretty cool.
So what we’ve done here is reduce many rules into one.
Going back to the example at the start of this post, we had 3 countries and 2 case types, which resulted in 6 rules. Now, we’ve reduced that down to just 1 rule, that handles all of these scenarios. Extrapolate that out to 10 countries and 10 case types (or more), and I’m sure you can quickly see how this can make your life easier.
Plus, when we add a new case type, or start supporting another country, we don’t need to change the rule. The rule will work as is.
Integers
Should your substitution value be an integer rather than a string, you would use %ld instead of %s. Example:
(objid > 0) -> “(“Region_%ld”,case_reporter2site:x_int_region)”;
Backslashes
A note about backslashes. Any names in the rule must be enclosed in double quotes. Since these double quotes are also inside the rule statement’s double quotes, you must include the backslash character (\) before each double quote. For ease of understanding, I’ve removed the backslashes from all of these examples.
For reference, here’s what a rule would look like with the backslashes in place.
(objid > 0 ) -> \”(\”%s_%s\”,case_reporter2site:cust_primaddr2address:address2country:name, calltype2gbst_elm:title)\”;
It’s a bit more difficult to read, which is why I removed them from the examples here. But you will need these backslashes if importing your rules using diet or dataex.
Wrap up
Again, this is definitely a more advanced syntax, but it can be super useful if you need it, and it’s a great tool to have in your toolbox to help prevent rule bloat and make it easier to manage your rules.
I’ve talked about reducing bloat before for business rules, and for status/transition workflows, so I guess it’s not a surprise that I’m now talking about it in terms of auto-dest rules as well.
It’s likely you haven’t thought about printf since you tucked your K&R book safely into your bookshelf years ago, but it’s nice to have some of that power available when you need it.
Now, where’s my awk book…?
Dig this?
Sign up to get information like this delivered right to your inbox.
