Troubleshooting Rules
  • 25 Apr 2024
  • 4 minute read
  • Dark
    Light
  • PDF

Troubleshooting Rules

  • Dark
    Light
  • PDF

Article summary

The Rules Editor is a powerful tool that 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:

  • Less is more: Use the fewest filters possible.

  • Stay standard:

    • Avoid custom SQL.

    • 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.

  • Keep ‘em separated: Multiple rules that filter directly and affirmatively perform better than a single rule with multiple OR statements.

  • Use Exclusivity Groups whenever possible:

    • All rules in the Exclusivity Group must use the same base.

    • Incorporate Do Nothing rules into your Exclusivity Groups.

  • Avoid character search filters:

    • f possible, avoid filters that use a character search (for example, School In List or Last Name Contains).

    • For example, instead of filtering on School In List (CEEB), try using the more efficient Geomarket filter instead.

Additional filter pitfalls:

If possible, avoid filtering on any of the following bases:

  • Source Format

  • Mailing Sent

  • Ping Data

The Source Format, Mailing, and Ping tables grow almost exponentially over time. As a result, filters searching across those tables become too computationally expensive.

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 rules, 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, it is possible that the record has 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. "Prospects").

Utilize the “Check Rules” function to see if one or more rules are processing especially 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.  

You can select New Query on a rule and explore changes to the filters to improve efficiency. The duration seen in Check Rules reflects the same or similar duration as the amount of time that it takes for the Matching Rows count to render in a query (basically, the time that it takes for just the filters to run on the records within that base). Therefore, you can explore changes within a query and get an immediate sense of whether those changes will result in a faster, more efficient rule that can consistently beat a timeout.

Tips

  • If rules are failing, check the Rule Log to view any errors. 

  • This log displays the most recent 25 errors experienced within the past 24 hours while executing rules for your database. If rules are not completing successfully, this log may be used to identify the rule that is causing the failure.

  • The Rule Log is located below 'Deferred Queues' within the Rules Editor.

  • When you have corrected or disabled erroneous rules, the Max Age displayed in the Rules Health tool will continue to increase until all records have been processed. Typically, Slate processes approximately 100,000 records every 18-20 minutes. Once all records have been processed, the Max Age will normalize.

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.


Was this article helpful?

What's Next