Troubleshooting Rules

The Rules tool is powerful in that it allows you to automate the movement of data in your instance. Generally speaking, sticking to the following principles will help ensure that you are building efficient rules within your database:

• Use the fewest number of filters as possible
• Avoid using custom SQL
• Use standard filters – custom filters should be reserved for queries
• Configure rules to filter directly – avoid OR statements
• Configure rules to filter affirmatively – avoid using NOT statements and NOT IN operators
• Separate rules whenever possible – multiple rules that filter directly and affirmatively will perform better than a single rule with multiple OR statements
• Use Exclusivity Groups whenever possible – and remember that all rules contained within the Exclusivity Group will need to utilize the same base. Try to incorporate “Do Nothing” rules into Exclusivity Groups as well
• If possible, avoid filters that utilize a character search (e.g. School In List, Last Name Contains, etc.). For example, instead of filtering on School In List (CEEB), try leveraging a Geomarket filter instead, which is much more efficient
• Additional filter pitfalls - if possible, avoid filtering on any of the following:
  • Source Format
  • Mailing Sent
  • Ping Data

  The Source Format, Mailing, and Ping tables will, in all likelihood, continue to grow almost exponentially over time. As a result, filters searching across those tables will become far less performative over time and can become too computationally expensive when used within rules and cause rules to timeout

At times, it can be difficult to determine why automation is not behaving as expected. The following steps are designed to help you better understand the actions taking place automatically in your instance so that you can make changes accordingly.

Determine whether the error is filter-based

• Using Preview Actions - look up an individual record to see for which rules the record meets the filter criteria. Preview Actions can be accessed from:
  • The student record when it has been recently updated by selecting "Preview Pending Actions"
  • The Rules Editor by selecting "Preview Actions" and selecting a particular record
  • Within the rule by selecting "Check Logic" to determine which filters your record does or does not meet the criteria for

Can one set of rules depend on the immediate outcome of another rule?

Rules do not run in the same order every time nor on individual records at the same time. Because of this, rules should not depend on the immediate outcomes of other sets of rules. Commonly referred to as daisy-chaining, this makes rules unpredictable and inconsistent. The only exceptions to this concept are Checklist Rules, Application Status Rules, and Bin Movement Rules. These rule types are hard coded behind the scenes to rely on the outcome of one to trigger the next.

Check the trigger for the rule

• If the trigger is “Upon Update (Deferred),” a record will only be evaluated by the rule if it has been updated recently. Ensure that the record(s) being tested has (have) been updated. This can be done either by:
  • Opening a tab on the Person Record and clicking save (no change necessary; you're tricking Slate into thinking an update has been made)
  • Running a Retroactive Refresh as an export destination in a Query
• If the trigger is “Upon Application Submission,” the rule will only fire at the time of application submission. If the student did not meet the rule criteria at that time, or if the rule was created after the application was submitted, no action will be taken on the record

Look at the exclusivity group for the rule

• Generally, checklist rules and field update rules should not have an exclusivity group.
• If a lower priority rule is not acting on the record in question, the record may have been caught by a rule of higher priority. You can use Preview Actions to investigate this
  • If you see a lock next to a rule, it means that the record has been "caught" by a rule of higher priority, and is thus removed from processing for rules of a lower priority
• All rules in the exclusivity group should have a unique priority assigned
• All rules in the exclusivity group should have the same base (e.g. "Person"). This includes ensuring that rules are built using only Configurable Joins bases or only Slate Template Library bases - not a combination of both

Utilize the “Check Rules” function to see if one or more rules are processing slowly

• Check Rules will determine how long each rule takes to run
• Check Rules will alert you to whether or not a rule has custom SQL

A payment was made but appears as "pending"

• When a payment is made through Slate Payments from a checking account, there is a delay while the payment is processed. During that time, the payment will appear as "pending." Typically checking account/ACH payments will complete in approximately 5 business days (i.e. not including weekends or holidays). Infrequently we've seen these payments take one or two additional days. If the payment shows as pending after 7 business days, please enter a Service Desk request in the Payment Integration category.