Application and Status Page Authentication (SSO Single Sign-On)
  • 13 Mar 2024
  • 3 minute read
  • Dark
  • PDF

Application and Status Page Authentication (SSO Single Sign-On)

  • Dark
  • PDF

Article Summary

Applicants have two primary methods for accessing their applications and status pages.

  • Slate authentication (default) using an email address and password.

  • Institutional Single Sign-on using credentials created in the institution's single sign-on system.

Slate Authentication

This is the default functionality in Slate. Applicant accounts are activated using their email addresses and a 9-digit PIN that is transmitted by email, in addition to the birthdate (optional) for verification purposes, which is not communicated by email. Upon activation, the applicant must set a password of their choosing. A salted hash is stored instead of plaintext passwords. The order of operations:

  1. Direct the applicant to the apply page by replacing "manage" with "apply" in the URL of your Slate database. For example:

    • Slate URL:

    • Authentication URL:

  2. The applicant provides:

    • First name

    • Last name

    • Email address

    • Birthdate (optionally)

  3. A system email, including a 9-digit PIN and the above link, is sent to the applicant's email address (also used as the user name).

  4. Upon accessing this link, the applicant must provide the PIN and birthdate for verification to create a password. This system email can be customized following the procedure in the System Emails article.

  5. Upon returning to the application, the applicant uses their email address and password to authenticate. If an applicant has forgotten their password, a system email can be sent with instructions to reset the password. This system email is sent automatically but may be customized following the procedure in the System Emails article.

Institutional Single Sign-On Authentication

If preferred, an institution may choose to create accounts in the single sign-on system to credential access to the Slate application. Slate has the ability to authenticate against one single sign-on system for both administrative users and applicants.

Use the following procedure to import the user name from the single sign-on system and direct applicants to the appropriate URL for authentication:

Add the SSO usernames for applicants to Slate. Create a source format to import the username from the single sign-on. The following data points are required:

  • unique ID (to match against the appropriate record in Slate)

    • username

2. Map the unique ID appropriately and the username to Record > Slate User Login Override.

After importing the usernames, direct the applicants to a specialized link that will instruct Slate to hand off authentication to your single sign-on system:

  • Slate URL:

  • Single Sign-on URL:

Using existing Slate credentials will provide the user access, but this can also create an inconsistent user experience. There are primarily three ways of handling this:



Friendly URL

Create a "friendly" URL that redirects to the special login page (for instance, could be redirected on the Slate side to, which mitigates some of the concern because it's an easier URL to publish. Then again, if the user bookmarks the actual portal, they would be sent to the standard login page upon return to the portal directly.

Slate Credentials

The link above includes a query string parameter of "r" that directs Slate where to send the applicant after authentication. This can be updated to send the applicant elsewhere, if necessary. For example, if your institution imports applications, you may change the parameter to /apply/status/ to send the applicant directly to the status page rather than the application:

Status Page URL:


Keep using Slate credentials until the applicant arrives on campus, which is a clean place and time to begin using new credentials for campus resources and stop accessing Slate.


Use SSO from the beginning of the process. All logins then go through the SSO, which can clutter it with records that don't need long-term access, but doing so would keep consistent credentials throughout the student life cycle. This option usually requires agreement from the organization's SSO administrators.

Batch Unsetting SSO Usernames

It is possible to batch unset the SSO Username value by:

  1. Querying for records that you want to unset the SSO Username for. This query should have a:

    1. Person-scoped unique identifier, like the person record's GUID

    2. Literal export that has a name, like "Clear SSO", but no value/Literal. This is the column you'll use to unset the SSO Username

  2. Exporting the results to your desktop.

  3. Importing the file using Upload Dataset. This import should be unsafe and match on existing records.

  4. Map the column with empty values from step 1 to "Record > Slate User Login Override" and enable the Null Handling setting.

    enable the Null Handling setting
  5. Import the file.

  6. Confirm the import made the desired changes.

Was this article helpful?