📚 Part of the series Application Building Phase 1: Initial setup

The second step in the application building phase of your Slate application is creating an application round.

This applies whether you’ll be importing applications from a third-party, using Slate-hosted applications, or both.

What is an application round?

In Slate parlance, “round” just means application type.

For your institution this might mean Undergraduate, Graduate, or some other high-level distinction.

Periods and rounds can also control the application process. For example, by limiting the number of applications a person can submit.

📖 Required reading:

• Before you get into the weeds, make sure you have an understanding of the overall structure of periods and rounds.

• Rounds must be associated with a period, so a period must be configured first. See Creating Application Periods if you haven’t already.

Best practices for setting up your rounds

When you go on to build out your own period and round structure, keep the following in mind:

Less is more

The applicant must select their round at the outset of their application experience.

To avoid overwhelming them with options, we recommend operating with as few rounds as possible. This also reduces your year-to-year round maintenance, like the inactivation and creation of new rounds.

If your applicants need clarification about which round to select on the /apply page, use fewer rounds, or only one. Then, you can manage application types at the field level. Manage application term values as an application-scoped field, not in the round.

Make the applicant’s choice of round obvious to them

In theory, you could make as many rounds as you have application types, reducing the number of conditional fields you’d need in the application; in practice, distinct rounds work best when it is clear to applicants which round they should select.

If you can imagine that an applicant might not be sure which of your rounds they should choose, take this as a hint that these application types should be represented by a field and prompt selected from within the application itself.

Let applicants differentiate their applications with custom fields

Use custom fields to represent narrower data.

It makes for a better user experience when applicants can share information through custom fields on custom application page-scoped forms, rather than forcing them to switch application types at the round level.

Data points that identify distinct populations or types of applicants (for example, enrollment term, a program of study, international, transfer, or scholarship qualifiers) can be captured and queried for within the application using custom application-scoped fields on application-page scoped forms and do not require the creation of separate rounds.

Creating an application round

Once a period has been established, a round or rounds may be configured and associated with the period.

1. Select Database from the main navigation.

2. Select Application Rounds.

3. Select Insert. A popup appears.

4. Configure the following settings:

   • Status: Inactive

     • This will be activated when you’ve finished testing the application.

     • If all applications are being imported, the round should always be set to Inactive.

   • Period: Select the active period from the two you created previously. In our case, Active.

   • Name: Enter a name for your application round, for example: Undergraduate Application

   • Short Name: Optionally enter an internal “short name” that appears as a tab on the applicant’s person record. In this case, 2024 UG.

   • Order: Dictates the order in which rounds appear to the applicant. In this case, 5.

   • Round Key: Used in application logic, automation, and communications for your application. Enter a year-agnostic code, like UG for Undergraduate.

   • Allow Multiple: Do not allow multiple applications

   • Locked: Unlocked

   • Hidden: Allow applicants to see their applications in this round

   • Protected from Rank: Rankable

     

5. Click Save.

🔁 To create a Graduate application round, repeat the preceding steps, updating the Name, Short Name, Order, and Round Key accordingly.

Result

• You’ve created an inactive Undergraduate application round for the active application period that restricts the applicant to a single application per period.

• You’ve may have also created a Graduate application round with the same settings.

Your requirements may differ from the settings we’ve selected here. See the full list of settings to understand if your setting selections should differ.

Application round setting descriptions

Status

• Required

• Set the status to Inactive until the Slate-hosted application is ready to go live.

• If all applications are being imported, the round should always be set to Inactive.

Folder

• Optional

• Keep your database organized by using folders.

• Select Other to create a new folder.

Period

• Required

• Ties the round to an application period

Name

• Required

• The round name visible to applicants

• Enter a descriptive name, like Undergraduate Application.

Short Name

• Optional

• Visible to internal users only

• Overrides the display name of the round on the application tab

Order

• Required

• Integer value that dictates the display order of the application rounds to applicants

Round Key

• Optional

• Enter a short-code that will identify this round type.

• For example, UG for undergraduate and GR for graduate, or ED for early decision and RD for regular decision.

• The round key is used in application logic, automation, and communications for your application.

• Omit year information so that the same round key can be used for future rounds.

Round Path

• Optional

• Overrides certain shared application files for a particular round

• Use-cases are limited

Deadline (ET)

• Optional

• The date and time (in Eastern Time) after which applications and their submission fees in this round cannot be submitted

  • Fees can have grace periods. See Payment Grace Period (Days)

• Formatted YYYY-MM-DD H:MM

  • So, if you want the deadline to be 12:00AM Pacific on 12/15/2020, enter 2020-12-15 3:00.

• For Slate-hosted applications only

• Note that deadlines can also be set and enforced using hard fails (submission requirement)

Payment Grace Period (Days)

• Optional

• Enter the number of days after your specified submission deadline that you will accept an application fee payment.

• For example, if the application submission deadline is January 1, but application fee payments will be accepted through January 15, enter 15 here.

Require Payment to Submit Application

• Optional

• Select Yes to require either payment or a waiver before the user can submit their application.

• 📖 Further reading: Require Payment to Submit Application

Allow Multiple

• Optional

• Select Allow multiple applications to let applicants submit more than one application to the same round.

• For Slate-hosted applications only

• 📝 Note: The same setting must also be configured on the application period to enable multiple applications per round.

Locked

• Optional

• Unlocked applications allow applicants to switch an application to a different round.  

• Locked applications cannot be moved to another round by the applicant.  

• For Slate-hosted applications only

• If multiple rounds share the same application questions and have different submission deadlines, select Unlocked.

• This configuration allows a potential applicant to change to a Round with a later deadline if the original Round has passed.

Hidden

• Optional

• Typically used by graduate institutions that refer applicants to other programs.

• Configuring a round as Hidden allows the applicant to not see this extra application during the review process.

• To display the hidden application at a later date, update the application to be in a visible round.

Protected from Rank

• Optional

• When there are more than one of a certain kind of object associated with a record, like applications, test scores, or addresses, Slate uses a set of rules to determine ranks for those objects. This usually comes up in querying, where you only care about the “rank 1” object.

• This setting defaults to Rankable, meaning the application is in the running for the aforementioned table ranking. This ranking determines which application is the highest-ranking, based upon application priority and application creation and submission dates.

• Standard application rounds (applications for admissions and enrollment) should always be Rankable.

• Applications for other items, such as summer high school programs or scholarships, should be set to Do not rank.

• 📝 Note: Applications in rounds set to Do not rank do not appear in the Omni Search.

• 📖 Further reading: Determination of Table Ranks

Custom Status Portal

• Optional

• This setting will override the Slate-delivered application status portal if a custom status portal exists.

Export Value

• Optional

• Configure up to 5 export values for the application round.

• Typically a short value or code that is used by external systems (such as an SIS) upon the consumption of application data from Slate.

➡️ Up next: creating application-scoped fields

You’ve created the large-scale structure that dictates whether applications in your database are active or inactive, and where they fall in the high-level organization of your institution.

Now, you’ll make the application-scoped fields that collect applicant information.

📚 Next article in this series: Application Fields