About Rules
Rules are a powerful feature that allows administrators to automate processes and streamline workflow. Rules are used throughout Slate to automate processes relating to person records, application data, and more. Here are some of the key benefits of rules:
-
Increased Efficiency: Rules allow colleges to automate repetitive tasks and streamline their admissions processes. For example, a rule can be created to automatically assign an application to a specific reviewer based on the applicant's geographic location, academic interests, or other criteria. This can save time and resources that would otherwise be spent manually assigning applications.
-
Consistency: Rules ensure that tasks are performed consistently and according to established guidelines. By automating tasks and enforcing standardized procedures, rules help to eliminate errors and inconsistencies that can occur when tasks are performed manually.
-
Flexibility: Rules are highly customizable and can be tailored to meet the specific needs of each college or university. This flexibility allows administrators to create rules that are tailored to their unique admissions processes and workflow.
SQL: Rules require no knowledge of SQL and they are always visible to Slate administrators.
Rule Bases & Types
For processes that run repeatedly in your Slate database, a rule can be configured to automate that function. Rule types, actions and examples are listed by base below:
| Rule Type | Automation Action | Example |
|---|---|---|
| Field | Replace, append, or delete a field value for records within a defined population | If the student type field is empty and the entry term is Fall 2020 then set the student type field to Freshman |
| Person Status | Update a record's person status to Prospect, Inquiry, or Applicant | If a record has an application then set the status to Applicant |
| Interaction | Add an interaction to records within a defined population | If the GPA field is > 4.0 and the Legacy tag exists then add a Watch Flag interaction |
| Tag | Set or unset a tag for records within a defined population | If the Parent 1 School key is Slate University or the Parent 2 School key is Slate University then set the Legacy tag |
| Test Optional | Set a "Test Optional" flag for test scores, preventing them from displaying on the a person record dashboard, in the Scores tab, or the Slate Reader, while still retaining the scores themselves in the backend. | If applicant answers "No" to application question "Would you like Slate University to consider test scores in your application?" then add Test Optional flag to their test scores. |
| Rule Type | Automation Action | Example |
|---|---|---|
| Activity | Add an activity to applications within a defined population | When a student submits the application add an application fee payment due activity |
| Application Status |
Update an application’s application status | When an application is submitted and has all checklist items fulfilled then set the application status to Awaiting Decision |
| Bin | Set or clear the bin and set the reader queue for applications within a defined population | If the application status is Awaiting Materials and the Bin is not assigned then set the Bin to Awaiting Materials |
| Checklist | Add, remove, and/or fulfill checklist items for applications within a defined population | Define the international checklist group for international records |
| Decision | Add a decision to applications within a defined population | If the applicant has paid their enrollment deposit then add the Deposited decision to the application |
| Field | Replace, append, or delete a field value for applications within a defined population | If an application has a Common App ID and the Application Type is empty then set the Application Type to Common App |
| Tag | Set or unset a tag for applications within a defined population | If an applicant answers Yes to “Have you applied previously?” then set the Reapplicant tag |
| Rule Type | Automation Action | Example |
|---|---|---|
| Field | Replace or delete a field value for records based on a form response | If the Student Type field is empty and the Entry Term is Fall 2020 then set the student type field to Freshman |
| Interaction | Add an interaction to records based on a form response | If a student was contacted through a telecommunications campaign then add an interaction |
| Tag | Set or unset a tag for records based on a form response | If a student submits an athlete recruitment form then set the Athlete tag |
| Rule Type | Automation Action | Example |
|---|---|---|
| Activity | Add an activity to records based on a form response | If a student was contacted through a phone-a-thon campaign then add an admitted student contact interaction |
| Bin | Set or clear the bin for records based on a form response | If an applicant withdraws their application through a Withdrawal form then clear the Bin |
| Checklist | Add, remove, and/or fulfill checklist items for records based on a form response | If the applicant fills out the financial aid form then fulfill the Financial Aid Information requirement |
| Decision | Add a new decision to records based on a form response | If the applicant accepts an offer by submitting the reply to offer form then add the Deposit Pending decision |
| Field | Replace or delete a field value based on a form response | If an applicant has a Common App ID and the Application Type is empty then set the Application Type to Common App |
| Tag | Set or unset a tag for records based on a form response | If an applicant answers Yes to “Have you applied previously?” then set the Reapplicant tag |
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?
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
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.