About Rules
Rules are used throughout Slate to automate processes relating to person records, application data, and more. Rules require no knowledge of SQL and they are always visible to Slate administrators.
For processes that run repeatedly in your Slate database, a rule can be configured to automate that function. For example, when repeatedly updating the Student Type field to the Freshman prompt based on the student’s entry term, creating a rule for that assignment would make strategic sense and create greater efficiency.
Best Practices
Resist the urge to immediately begin writing rules for every business process in your office! After developing a familiarity with Slate, processes and practices that may benefit from using the Rules Editor will become more apparent.
Creating a Rule
1. Select Database on the Slate navigation bar.
2. In the Automations section, click Rules. The Rules overview page appears.
3. Click New Rule. An Edit Details popup appears.
4. Configure each setting* as necessary.
5. Click Save.
|
*Click here for a complete listing of all setting descriptions. |
How Rules Work
What causes records to be queued for the rules?
When inserts, updates, and deletes occur for data associated with a record, that record is added to the queue for a given database. These updates can be caused by a manual action on the record, a data import, or an automated process. The next time the rules run, the updated record will then be evaluated for any changes.
If a particular database has more than 100,000 records queued, the thread picks the top 100,000 and leaves the rest in the queue for the next cycle.
What happens when the rules run?
Rules run in two phases: one to determine eligible records, and one to perform the actions.
Phase 1: The rules first determine who is eligible
- Rule filters evaluate all records, whether or not they were updated.
- Each rule must complete in no more than 5 minutes to identify the records meeting the filter criteria.
- Once the filters have been evaluated, the thread has up to 5 minutes to compare the aggregate results for all the rules (who qualifies) to the records that have been queued (who must have action taken) and determine what should be done.
- Eligible records that meet the filter criteria in Phase 1 move on to Phase 2.
What happens if a rule times out at 5 minutes?
The entire cycle fails and the GUID of the offending rule will appear in the Rule Log. Check Rules is meant to help catch individual rules that are at risk of timing out based on poor filter performance. Note that the timeout for rules running as a background process is 5 minutes, but a rule will show ERR in Check Rules at 1 minute when run in the browser.
As part of phase 1, exclusivity groups and do-nothing rules only come into play at the very end, when determining the action to be taken. All records are evaluated by the filters in all of the eligible rules (application records by application-scoped rules, for example). Even if a record would be caught by the first rule in an exclusivity group, it’s still evaluated by the filters in all subsequent rules in the same group. It is best practice not to duplicate filters from higher priority rules into lower ones, but there may be some cases where including the filter helps improve the efficiency of a given rule. Similarly, rearranging the sequence of the filters in a particular rule may improve efficiency.
Phase 2: The actions of the rules are executed.
- The rules have up to 15 minutes to take all of the actions for that stage on the records that have qualified.
- The rule actions are aggregated by type. For example, field modification (insert, update, delete) actions, and all actionable records are handled together.
- If the cycle fails during phase 2, no GUID is listed in the Rule Log because the failure isn’t the result of a specific rule. the failure is the result of the aggregate work needing more than 15 minutes.
What should we try if no GUID is listed in the Rule Log?
Look for rules that use a custom SQL formula to take an action or are otherwise acting on large tables.
What happens when the rules finish?
If the cycle fails, all potential updates are rolled back to what the instance looked like at the beginning of the cycle, and the instance will have to wait for the next time it is eligible in the queue for another worker thread to pick it up. Until or unless an instance can execute its allotted rule updates in an appropriate amount of time, no actions or updates will be taken on that instance, causing a rule backlog.
Once a cycle completes successfully, records with actions taken on them are placed back into the queue for a second pass as part of the next cycle, while records that were not actioned are removed from the queue after the first pass. So when the next cycle begins, the records that are in the queue might be:
- Records that have been recently updated, awaiting their first pass
- Records from the previous cycle that are awaiting their second pass because the first pass resulted in a change