Getting Started with Checklists

The primary purpose of checklists is to serve as a visual indicator of items required of applicants after they submit an application. These items will display on an applicant's status page, accessed after the applicant submits his/her application.

 Tip

Did you know? Slate.org may be used to share information regarding applicant data such as Checklist items between undergraduate admission offices and high school counselors, independent counselors, and community-based organizations. See Slate.org Application Sharing Settings for more information.

Make a List of Required materials

  Best Practice

A recommended best practice is to use Excel (or even pen and paper if necessary) to create an outline of which materials are required of each applicant type before building anything in Slate.

Once a structure of required materials has been established, corresponding checklist items can be considered to visually indicate these requirements to an applicant.

  • Checklists are meant to serve as a visual indicator (more like a label) of what a Slate partner requires of an applicant.
  • Materials are the actual materials/forms themselves that an applicant will submit and which will live on that person's record/application.

Before building any checklist items in Slate, it's important to consider what types of materials should be required of an applicant. Here are some frequent examples:

POTENTIAL MATERIALS TO CONSIDER:
Application Teacher Recommendation 1 Teacher Recommendation 2 Dean Recommendation High School Transcript
College Transcript Essay Transfer Essay ACT / SAT Scores GRE / GMAT Scores
Passport Resume Reply to Offer Form    

Additionally, when building materials in Slate, it's important to note that all materials will fall into two distinct types:

  • System Materials - System materials already exists in the database (designated with a 'sys:' in the material key field). These system materials will generate checklist items automatically based on various actions taken by persons/applicants.  Important information on system materials will follow in the coming sections.
  • Custom Materials - Every other material outside of Slate's auto-generated system materials will be a custom material. These custom materials are the materials which Slate partners will create. Click here for further information on how to create a custom material.
Checklists Functionality and Display Information

Checklists display information in a number of ways. Once items have been added to an applicant's checklist, they will display with the following indicators:

  • Received items will display as 'Received' with a green check mark and the date that the checklist item was fulfilled.
  • Awaiting items will display as 'Awaiting' with a red X.
  • Optional items will display with an 'Optional' label.
  • Waived items will display as 'Waived' with a grey check mark and the date that the item was waived.

Groups

As a best practice, checklist items should be assigned to a group whenever possible. This is due to how checklist groups function as this 'group' functionality will likely influence how a partner wishes to add/remove items from their applicant's checklists. This adding/removing of checklist items from a checklist is done via rules and will be discussed shortly.

Legend - Group Name
All First Year Transfer Domestic International

 

Requirement First Year First Year International Transfer Transfer International
Application X X X X
Teacher Recommendation 1 X X X X
Teacher Recommendation 2 X X    
Dean Recommendation     X X
High School Transcript X X    
College Transcript     X X
ACT / SAT Scores X   X  
Essay X X    
Transfer Essay     X X
TOEFL / IELTS Scores   X   X
Passport   X   X
Resume     X X

The "Group (Optional)" setting for checklist items allows for the following functionality:

  • Assigning checklist items to a particular group allows for multiple checklist items to be combined into a group and added to an applicant's checklist at the same time. This eliminates the need to construct numerous checklist rules instructing Slate when to add each individual checklist item.
  • 'Groups' also correspond to populations of applicants. That is, if a checklist group is assigned via a rule, and that rule focuses on a specific population of applicants, when an applicant qualifies for the checklist group rule, all items in that checklist group will be added to their checklist. Conversely, should an applicant fall out of that particular population in the future (i.e. he/she no longer meets the filter criteria for the checklist group rule), all items associated with a specific checklist group will be removed from his/her checklist.

For example, say a Slate partner assigned multiple checklist items to a "Freshmen" checklist group. Continuing, say a "Freshmen checklist group" rule evaluated on the following filter:

  • Round IN Freshmen

Any applicant in the "Freshmen" application round would qualify for this example rule and all checklist items in the "Freshmen" group would be added to his/her checklist.

Furthermore, if an applicant were to then change his/her round from "Freshmen" to "Transfer" they would then no longer meet the filter criteria for the "Freshmen checklist group" rule, and the "Freshmen" group checklist items would be removed from their checklist.

This is extremely useful as every time an application is updated checklist groups re-evaluate and update accordingly.

  Best Practice

One More Time -- Use Groups Whenever Possible.

A best practice is to always try to assign each checklist item to a group and to use checklist group rules to add/remove items from an applicant's checklist, even if that checklist group is only a singular item.

Any checklist items that are added manually, or via a rule that does not define the checklist group, will remain on an applicant’s checklist regardless of whether or not the applicant no longer meets the criteria for the checklist rule that added the item.

Make Checklist Rules

Once checklist items have been created, and checklist groups have been assigned, only one rule needs to be written per checklist group. These rules will assign all checklist items within a particular group to applicants who meet the criteria for that rule.

To construct checklist rules: 

  1. Select Database on the top navigation bar and select Rules Editor.
  2. Select New Rule.
  3. Enter the following school report configurations:
    • Population - Select 'Applications.'
    • Type - Select 'Checklist.'
    • Trigger - Set to 'Upon Update (Deferred).'
    • Folder - Assigning folders is critical good for organization. For checklist rules, a recommended folder is "Checklists."
    • Exclusivity Group - Checklist rules should NOT be assigned an Exclusivity Group.
    • Status - Set to 'Preview.' Once the rule is complete, set to 'Active' within the finalized rule.

For checklist rules, there are a few key settings to keep in mind:

An example of a checklist rule would be if a Slate partner had an "International" checklist group that should be assigned to all international applicants, they might construct a rule like this:

Through this rule (once the rule was set to 'Active' status), every time an applicant was designated as a 'Foreign National' for their citizenship status, they would have the "International" checklist group added to their checklist.

  Best Practice

Test in Test! 

If rules are created in a production environment, leave these set to 'Preview.' Then, refresh the test environment to copy over any newly-created rules. Once new rules have been copied over to test, set them to 'Active' there and begin testing. Once rules have been thoroughly tested in the test environment, replicate any changes to these rules in production and switch their status to "active."

Additionally, it may be beneficial to run a retroactive refresh (using Query Builder) on appropriate records to ensure that the proper checklist items are assigned and displaying to applicants.

Important

Application Period must be "Active." Checklist rules only run on applications that are in an active application period. While the application rounds can be either active or inactive (depending on the nature of your process) without impacting checklist functionality, the application period must be active. This setting prevents checklist rules from firing on previous or historical applications, effectively preserving those checklists as they were at the time their application period was inactivated.
Was this article helpful?
11 out of 26 found this helpful