Actually, we did that on purpose. The default rules installed by setup cannot be edited or deleted. Allow me to explain…
The system ships with 4 default rules that define our basic call handling behavior. For direct calls into the system, you have “Live Record”, “Attempt Sign In” and “Default Call Handler”. For calls that forward into voice mail you have “Attempt Forward to Greeting”, “Default Call Handler”. When calls come into the system we apply these rules in the order in which you see them (from the top down) depending on if the call was identified as a forwarding call or a direct call (if the switch doesn’t tell us one way or the other we default to forwarded).
Direct Calls:
The first rule we check is “Live record” which is supported by a few switches out there. If the switch integration tells us it’s a live record request, we take the calling party information and look them up in the directory. If they are a known voice mail subscriber, we simply start recording what’s on the line and leave it as a message for that user. If not, we move on to the next rule in the list.
The next rule is “Attempt Sign In”. If the calling station corresponds to the extension number of a subscriber in our database, we send the call to the subscriber sign in conversation. If not, we move on to the next rule.
The last rule is “Default Call Handler”. This is our “backstop rule” and will route all calls that get this far to the “opening greeting” call handler.
Forwarded Calls:
The first rule it tries is the “Attempt Forward to Greeting”. If the forwarding station from the switch corresponds to the extension number of a subscriber in the system, we send the call to the greeting of that subscriber. If not, we move on to the next rule.
The last rule is the same as for direct calls, “Default Call Handler”. When all else fails you get the opening greeting.
If we let these be edited and/or deleted it essentially can “break” the default behavior of the system. We had a number of problems with this in the field on early versions of Unity so we opted to introduced the concept of “uneditable” and “undeletable” rules.
Now if you want to modify the behavior, simply add a new rule at the top of the list. As mentioned above we apply these rules from the top down. You can move rules up or down so they get evaluated before or after the default system rules, but you can never move a rule lower than the “Default Call Handler” rule since no call will fail that rule. Just be careful and make sure you test your rules. The “Call Viewer” application (found under the Unity program group) was designed just for this purpose. It shows all the information coming from the switch and each column corresponds to a field on the rules page that you can route calls based on. It even has a “stay on top” function so you can keep it on top of the SA page showing the rules while you make test calls to see what the switch is sending us and making sure the call goes where you want it.
Kind of a long, rambling answer but I hope this makes it clear why we do it that way. The routing rules are actually really powerful and I think they’re under utilized in the field… I get a lot of “you can do that?!” from folks when talking about them.
If any of this isn’t clear or you’ve got other questions about how to use routing rules, let me know.
Jeff Lindborg
Unity Product Architect
Active Voice
jlindborg@activevoice.com
http://members.home.net/jlindborg
