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.

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.