The primary purpose of checklists is to serve as a visual indicator of required items for applicants after submitting an application. These items appear on an applicant's status page, and can be accessed after the applicant submits an application.

Tip

Did you know? Slate.org can 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

Use Excel (or even pen and paper if necessary) to create an outline of the materials required for each applicant type before building anything in Slate. After establishing a structure of required materials, consider the corresponding checklist items to indicate these requirements to an applicant.

• Checklists are meant to serve as a visual indicator (like a label) of what a Slate partner requires of an applicant.

• Materials are the actual materials or forms that an applicant will submit. They will live on that person's record or application.

Before building any checklist items in Slate, consider the types of materials required from an applicant. Here are some typical examples:

Additionally, when building materials in Slate, note that all materials fall into two distinct types:

• System Materials: System materials already exist in the database (designated with a "sys:" in the material key field). These system materials generate checklist items automatically, based on various actions taken by persons or applicants.  Important information on system materials is provided later in this article.

• Custom Materials: Every other material outside of Slate's auto-generated system materials is a custom material. These custom materials are created by Slate partners. Click here for additional information creating a custom material.

Checklists Functionality and Display Information

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

• Received items appear as "Received" with a green check mark and the date that the checklist item was fulfilled.

• Awaiting items appear as "Awaiting" with a red X.

• Optional items appear with an "Optional" label.

• Waived items appear as "Waived" with a grey check mark and the date that the item was waived.

Groups

Assign checklist items to a group whenever possible. This is due to how checklist groups function, where the "group" functionality will likely influence how a partner wishes to add or remove items from their applicant's checklists. This adding or removing of checklist items from a checklist is done through rules, and is covered later in this article.

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 with 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 (that is, the applicant no longer meets the filter criteria for the checklist group rule), all items associated with a specific checklist group will be removed from their checklist.

For example,  if a Slate partner assigned multiple checklist items to a "Freshmen" checklist group, and a "Freshmen checklist group" rule is evaluated on the 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 their checklist.

Furthermore, if an applicant were to then change their round from "Freshmen" to "Transfer," they would 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, because every time an application is updated, checklist groups re-evaluate and update accordingly.

  Best Practice: Use Groups Whenever Possible

Always try to assign each checklist item to a group and to use checklist group rules to add or 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 through 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 are created, and checklist groups are assigned, only one rule needs to be written per checklist group. These rules assign all checklist items in a particular group to applicants who meet the criteria for that rule.

To construct checklist rules:

1. Select Database on the navigation bar.

2. Under Automations group, click Rules.
   

3. Select New Rule. The Edit Details popup appears.

   

4. Enter the following configurations:

   • Name: Give the rule an appropriate descriptive name.

   • Base: Select Applications. The Type menu appears.

   • Type: Select Checklist. The Trigger menu appears.

   • Trigger: Set to Upon Update (Deferred).

   • Folder: Using folders is highly recommended for good organization. For checklist rules, a recommended folder is "Checklists." If desired, selecting Other opens a new field to name and create a new.

   • Exclusivity Group: Checklist rules should NOT be assigned an Exclusivity Group.

   • Status: Set to Preview. Once the rule is complete, set to Active in the finalized rule.
     
     

5. Click Save.

For checklist rules, keep these key settings in mind:

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, "International" checklist group would be added to their checklist.

  Best Practice: Test Rules in Test!

If creating rules in a production environment, they should be set to Preview. Then refresh the test environment to copy over any newly-created rules. Once new rules are copied over to test, set them to Active there and begin testing. Once rules are 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 appearing for applicants.