Troubleshooting Rules

The Rules Editor is a powerful tool that allows you to automate the movement of data in your instance. 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.  

  Tip

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.

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.
Was this article helpful?
1 out of 5 found this helpful