General

Why shouldn't I import the application as submitted?

Scoir receives two notifications during this process. The first is upon creation of the application to let them know that they can send the applicant to the Coalition Supplement form. The second is upon submission of the application. It is important for this submission notification to accurately reflect the applications that you consider submitted for multiple reasons:

• Scoir displays to applicants the submission status of their applications. If the application appears complete in Scoir, it reduces the transparency into the process for the applicant.

• Scoir is able to encourage applicants to complete any incomplete applications. If Scoir receives the notification that the application is complete immediately, then your institution will not benefit from Scoir's partnership in this process.

• Scoir will invoice your institution monthly for completed applications using the application status in Scoir, so it is essential that the invoice correctly reflects the applications that you consider complete.

I have never had an unsubmitted application in my system before. What do I do with them?

The submission status of an application is just another data point describing it. You can use that information to perform more nuanced reporting, and you can even use it to drive a different application status (that is, Awaiting Submission). 

Suppose you don't want to utilize this additional data point at the moment. In that case, applications that are not submitted can be treated like any other application that doesn't include all materials required for reading (that is, Awaiting Materials).

Regardless of how you choose to handle these unsubmitted applications, this data point can be used to drive communications to encourage applicants to return to complete their Coalition Supplement form.

What happens if an applicant doesn't submit the Coalition Supplement form immediately? How will they get to it later?

If the application is not submitted, the applicant will be directed to complete the Coalition Supplement form when they log in via single sign-on from Scoir or Slate.org or if they open the application when logged in using the direct login method. The submission status of the application drives this functionality, which is why it is highly recommended that the application is not set to the submitted status until the form has been submitted.

Additionally, Scoir can nudge applicants who have not yet completed the Coalition Supplement form, and your institution can also send communications to encourage completion.

Will PDFs of the Coalition Application be available?

Application and supporting documents are imported using the ScoirMaterials source format. The ScoirMaterials source format is loaded into the databases of all Coalition members, and several source fields are pre-mapped to standard destinations within Slate.

This source format is configured to import a ZIP archive containing PDFs and an index file containing information about each PDF in the archive.

For additional information, see the Coalition Documents: Scoir Materials article.

How will I know if an application is a Coalition application?

There are a few ways that you can tell if an application came from Coalition. If you need to use the application source as a filter, for example, to drive queries or reporting, you may want to create an Application Source field with a prompt for each of your application sources. In the CoalitionApplicationProfile source format, this field can be mapped with a static value to the Coalition source prompt.

Another way to determine whether the application is a Coalition application is because these applications will all have the Coalition Application ID field set.

Additionally, each application originating from the Coalition integration through Scoir will have source data associated with the CoalitionApplicationProfile source format.

Application Fees

Do we need to do anything special if we do not charge an application fee?

If you do not charge a fee for the application, delete the payment widget from the Coalition Supplement form.

If I capture the application fee on the Coalition Supplement form, what should I do with my existing Application Fee rules?

Suppose your institution is adding an application fee via a rule upon application submission. In that case, you can prevent an additional payment-due activity from being added by excluding these applications from that rule. Use an exclusivity group where the Coalition applications are excluded via a Do Nothing rule ordered prior to the rule that adds the fee.

How should I handle the fee waiver if I do not capture the application fee on the Coalition Supplement form?

If you are using rules to handle the application fee rather than the supplement form, then the fee waivers will also need to be handled using rules.

When determining if money is owed, Slate sums the total amounts of the Payment Due activities for a payment account and subtracts from it the combined total amounts of the Payment Received, and Payment Waived activities.

To waive all or part of an application fee, add the normal Payment Amount Due activity to all records and add a Payment Waived activity for the amount that should be waived for the records eligible for a fee waiver. For example, if the application fee is $75, and the application is eligible for a full application fee waiver, then two activities should be added to the application for the payment account associated with the application fee: Payment Due: $75 and Payment Waived: $75.

To use a rule to apply fee waivers:

1. Create a rule using the Applications query base with the type Activity

2. Add filters to define which applications should receive the fee waiver. The filters used will depend on how you store the fee waiver eligibility data. The Coalition Application Profile documentation covers some possible options and provides an explanation of the Coalition fee waiver fields.

3. Under Action:

   • Select Payment as the Code.

   • Select Payment Waived as the Payment Type.

   • Enter the fee amount to waive as the Payment Amount (e.g., if the application fee is $75, to waive the full amount, enter 75.)

   • Select the application fee payment account as the Payment Account.

Make sure that your Payment Due activity is still added to the application. This rule should not be within an exclusivity group that contains the rule that adds the application fee.

Applicants are being required to submit a payment if they choose the “Save for Later” option on the form. When they return to the form to complete it, they are required to submit a payment again to submit the form. How do I prevent this from happening?

When a payment widget is displayed on a form, the collection of payment is required to submit the form by the payment processor (Stripe), regardless of whether the applicant uses the Save for Later button or the Submit button.  If the applicant pays while saving for later, upon returning to the form, if the payment widget is still displayed, the applicant will be required to enter payment information again.

If your supplement form has Save for Later enabled, it is important to add logic to the widget so that the applicant is not prompted to pay each time the form is saved. 

The recommended method to display the widget only when the applicant is ready to submit is to add a checkbox form field toward the end of the form asking if the applicant is ready to submit and pay. The field must be configured as required to prevent submission without the applicant checking this box.  Conditional logic on the payment widget can reference this field so that the payment widget appears only if that checkbox is checked. Further instructional text can be included, such as "Check this box once you have finalized everything and are ready to submit the supplement and pay."

SSO, Credentials, and Security

What will the Scoir single sign-on (SSO) process look like for applicants?

Scoir single sign-on provides applicants with a seamless entry point to complete their Coalition Supplement form or to view their application status portal by selecting that application within the Scoir platform. The applicant is not presented with the Slate login screen during this process because Scoir is sending signed, encrypted data that certifies the identity of the applicant, and this data is used to handle the authentication within Slate.

Is the Scoir single sign-on like the social login options like Google, Facebook, and LinkedIn?

No. Scoir single sign-on is available for applicants while they are logged in to the Scoir platform. When an applicant views their in-progress and submitted applications in Scoir, they may choose to open an application sent to a Coalition member college. At this point, Scoir will send the request to Slate to initiate single sign-on to authenticate the user within that Coalition member's Slate database. Once complete, the applicant is directed to view their Coalition Supplement form (if not yet submitted) or the application status portal within Slate without presenting the login screen.

In contrast, social logins are optionally enabled by institutions to provide applicants with alternative methods of logging in when presented with the Slate login screen. An applicant with a Coalition application may still use these social login options just as they would use standard credentials when presented with the login screen; however, if they come to Slate directly from Scoir, the Scoir SSO process handles the authentication. So, they will not see the login screen in that particular circumstance.

How is the data secured in transit?

Applicant data is sent from Scoir to Slate in two scenarios: the initial post of profile data and a smaller set of data included in every single sign-on (SSO) attempt.

In both cases, the data is encrypted during transmission using the most up-to-date version of the standard Transport Layer Security (TLS) protocol. This prevents data from being stolen or altered by any systems that the data may flow through.

The SSO protocol includes an additional layer of encryption, by which the data is encrypted by Scoir using a proprietary certificate and then decrypted in Slate. In addition to preventing access to the data in transit, this also provides assurance that the data came from Scoir and that Scoir certifies that the applicant is identified and authorized. Based on that assurance, we can allow the applicant into Slate and positively identify the correct application.

How can I create normal Slate login credentials for new accounts that do not yet have a password or PIN?

There is a mapping destination under the Record category called Generate PIN. In the source format, a Static Value Mapping can set this destination to Yes, generating a PIN for records where a password or unexpired PIN do not yet exist. This method generates the PIN, but it does not automatically send communications.

A Deliver mailing targeting records with submitted applications can be used to send the PIN and information about how to log in to view the status portal once they have completed the Coalition Supplement form.

These applicants will continue to have access to log in to view the status portal through the Scoir single sign-on method.

Will applicants be able to see their checklist items and decisions in Scoir or Slate.org?

Applicants are driven to your status portals that you designed for them to view. Single sign-on options make it easier for them to get from Scoir or Slate.org to their status portal, but these items are never displayed elsewhere.

Does Slate.org single sign-on (SSO) need to be enabled for the Scoir SSO to work?

No. Scoir SSO functions independently from Slate.org SSO.

Do applicants who apply through this integration have to use single sign-on through Scoir to log in?

No. If they are coming from Scoir to Slate, then authentication will be provided through the Scoir single sign-on, but they can create passwords for their accounts and log in just as any other applicant could.

Can we still provision credentials for applicants to log in, either via a Slate password or our own institution-hosted single sign-on environments?

Yes, you can absolutely still provision accounts using any method you are already using. Single sign-on through Scoir is used to make it easier for applicants to log in to view their status portals, but they still have the ability to log in to Slate using normal login methods as well.

Will students be encouraged to only access the status portal through Scoir?

No. Applicants will be able to view their in-progress and submitted Coalition applications while they are logged into Scoir, which is a platform that many of them are already using. Providing the ability to view their application status portal by selecting the application within Scoir and using SSO for authentication makes it easier for applicants to manage their applications. They are still able to log in to view the status portal using any other method that you make available for your applicants, including:

• Normal Slate credentials

• Institutional SSO

• Slate.org SSO

• Social Login (Facebook, Google, or LinkedIn)

The Coalition Supplement Form

What is the best way to encourage completion of the Coalition Supplement form?

Ask only the necessary questions on the form. If an applicant needs to look up information, or if they need to write a long essay, they are unlikely to complete the form immediately. Remember, you can always request additional required information post-submission by adding any other required or optional items as checklist items.

I really don't want unsubmitted applications to exist in Slate, ever, even though you keep saying we should... Is it really a problem?

While not ideal, you may choose to mark the applications as submitted when they come in through the CoalitionApplicationProfile source format. Since this limits their understanding of the application status in Scoir and prevents standard functionality to direct them to the Coalition Supplement form, it is important that you make a checklist item for the Coalition Supplement form so the applicant knows that they do need to complete it when they view their status portal.

What will the branding on the Coalition Supplement form look like?

The Coalition Supplement form is co-branded. Your institutional branding will appear (as with any form), and the Coalition Application logo will appear as part of the header in the form.

Can we use our existing Slate application pages in place of using the Coalition Supplement form?

Using the Coalition Supplement form will help ensure applicants have a consistent experience as they apply to Coalition member colleges.

The Import Process

Should we be concerned about database contention with the real-time processing of the application creation?

No. Since the payload consists of just a single application, it minimizes the rows being manipulated by the system while it processes. Additionally, Scoir is putting in place a notification system to students, so that, should a delay occur for a particular applicant, the applicant will be notified and told when the application is available to complete.

How immediate is immediate? Will there be a delay? Is it dependent on rules running?

As soon as Slate receives the profile data from Scoir, it is processed using the remap settings you configured. Once it completes the import process, Scoir will receive a notification and will send the applicant to your Coalition Supplement form.

Rules run as part of a background process, and this process is not dependent on rules running for the record.

Will the immediate processing of the application import push back our other imports?

The applications created from the integration through Scoir are not performed by the background process threads that run normal imports, so these applications are not skipping ahead of the queue, they're just processed separately. The process is analogous to a person submitting a form in your database. Other processes, such as form submissions from other people, imports, rule executions, etc. are able to run at the same time. Database lock contention can happen any time multiple processes are attempting to update the same record at the same time - one process has to wait for the other to finish. This is the case with any updates that occur within a single database and are generally rare, but are more likely when files are imported that touch most records in the database, which is why we recommend limiting the frequency of large updates, including only records that have changes, and timing large imports to occur during off-hours.

How will we be able to test everything before we go live?

Scoir will provide an opportunity to validate your integration via a step-by-step activation wizard, which will let you ensure data and applicants flow correctly into your Slate instance. Additionally, Scoir will provide access to a sample data file that can be manually uploaded to the source format during any step of your mapping process so you can see sample data.

Mapping Data

Will applications begin coming in as soon as we set the Remap Active flag on the CoalitionApplicationProfile source format to Active and the Coalition Supplement form's status to Confirmed?

Setting these flags to active just allows Slate to begin importing and accepting the data, but your application will also need to be turned on in Scoir before real applicants begin coming in through this integration. It is perfectly safe to set these to active while you test the application flow prior to activating your application in Scoir.

What if our application rounds rely on knowing the entry term? How will we map the round if the entry term is not included in the initial data sent from Scoir?

Your institution will configure the round options that are available for selection, so you can include each of your term-specific application rounds as options in Scoir, and then map them to the matching round values in Slate. See the Application Round Considerations section of the CoalitionApplicationProfile source format article for more information on mapping rounds.

Many sections in the profile have multiple prompt options for students (for example, ethnicity or pronoun). How should those be mapped?

1. One common option uses a single field, configured to store multiple prompt values. Race/Ethnicity is typically configured this way.

   1. Map each source field (for example, gender_1, gender_2, gender_3, gender_4, and gender_5) to the same field in Slate.

   2. On the Prompt Value Mappings page, append each of the possible values in the field and map them to the corresponding prompt within Slate.

   When the data is imported, it will store each of the options selected by the applicant in that field.

2. Another option employs multiple fields, each storing a single value. For example [Field Name] 1, [Field Name] 2.

   1. When mapping these fields from the import, map the source fields to the corresponding field in Slate (for example, gender_1 to the Gender 1 custom field, gender_2 to the Gender 2 custom field, and so on).

   2. On the Prompt Value Mappings page, for eac

   When the data is imported, the single prompt value for each of those fields (when applicable) will be stored. For example, if an applicant lists just two genders, then Gender 1 and Gender 2 will be populated, but Genders 3-5 would be blank for that record.

There are a lot of ethnicity fields in the application profile. How should those be mapped?

How you map ethnicity fields depends on your institutional needs.

If your institution only captures broad categories for ethnicity (for example, American Indian or Alaska Native; Asian; Black or African American; Native Hawaiian or Other Pacific Islander; and White), then you can map the five fields: ethnicity_1, ethnicity_2, ethnicity_3, ethnicity_4, and ethnicity_5 to your race/ethnicity field, which is generally configured to store multiple values. On the Prompt Value Mappings page, simply append each of the possible values in the file (I, A, B, P, and W) and map them to the corresponding prompt value for each of these five source fields.

If your institution also captures more granular information about ethnicity (for example, specific backgrounds of Guam, Hawaii, or Samoa for those who specify that they are Native Hawaiian or Other Pacific Islander), then each of the specific ethnicity fields can also be mapped to your race/ethnicity field. The specific ethnicity fields have the field pattern:
ethnicity__# For example, Native Hawaiian or Other Pacific Islander is assigned the letter "P", so the background fields for that data are ethnicity_p_1, ethnicity_p_2, ethnicity_p_3, ethnicity_p_4. Remember to map the prompts for these values on the Prompt Value Mappings page.

In addition to selecting a specific background from the list of options, applicants are also able to select that their background is not listed. As such, an "other" field for each of the ethnicities containing the free-text data entered by the applicant is also sent (for example, ethnicity_p_other). If you choose to import this data, these fields should each be mapped to their own field configured to store a single text value (e.g., Pacific Islander: Other).

How can I see the type of data a field contains, or what the possible option values will be for the imports?

Information about the data coming from Scoir can be found in the Application Profile Specification Guide from Scoir, which can be requested here.

Configuring the Reader

Can I display the Coalition Application Profile PDF in the Reader?

Yes. Follow the steps in the tabs section of our workflows article (or the legacy workflow configuration article) to add a material to a tab in the Reader with the type Material. Then, to include that material type on the selected tab, select the material type that the ApplicationProfile document type is mapped to in the ScoirMaterials source format.

Can I use an Auto PDF to display the Coalition Application Supplement in the Reader?

Yes. Follow the steps in the tabs section of our workflows article (or the legacy workflow configuration article) to add a material to a tab in the Reader with the type Form/Event/Scheduler. Then select the Coalition Application Supplement form from the Form/Event/Scheduler list. Select Auto PDF as the template.

Application Sharing and Slate.org

Is application sharing required for this integration to work?

No, but it is recommended to allow for greater transparency in the admissions process for applicants and their school counselors.

Should I turn on application sharing with Slate.org?

Yes! Application sharing in Slate.org provides greater transparency into the admissions process and promotes a more informed dialog between students and their counselors. It also streamlines counselors' management of checklist items that they must fulfill, such as transcripts and school reports.

If we share applications with students in Slate.org, do they need to still use the status portal?

Application sharing in Slate.org helps students see a broad overview of where their applications are in the admissions process and provides them with a one-click (via Slate.org single sign-on) method to log in to view their status portal to see more specifics.

Applicants are always encouraged to view their checklists and open their decisions by viewing their applicant status portal for each individual application. As such, specific decision information and the actual checklist items are not displayed to them in Slate.org. Instead, applicants are able to view the specific status of the application that was shared with them, and if your institution has elected to share that a decision is available for them to view, then they will see this notification, but not the actual decision itself.

Are the sharing settings for Slate.org configurable? What if we only want to share some information, or we don't want an internal status to be publicly available?

There are a lot of customization options for sharing:

• Application Round: Each individual round can be configured as shareable or not shareable, and each round allows filters to be added to further limit the shared applications. Additionally, the name of the round to display can be individually configured for both counselors and applicants.

• Application Status: Each individual application status can be configured as shareable or not shareable. The name of the status can be individually configured for both counselors and applicants, and the specific stage of the admissions process that the status belongs in is configurable as well.

• Checklists (applicable to counselors only): The checklist items can be configured as shared or not shared. There is an additional configuration for shared checklist items to hide the checklist if the application has an unshared released decision.

• Decision Status (applicants only): Decisions will never be shared with applicants within Slate.org; however, you may elect to share that a decision is available for them to view in their status portal.

• Decisions (counselors only): Each individual decision can be configured as shareable or not shareable. If a decision is shared, a display name may be set for the decision. There is an additional option to allow the decision to be shared only after the applicant has viewed the decision or a configurable number of days after the decision release.

• Materials (counselors only): Specific materials can be made available for counselors to upload supporting documents for the application directly from Slate.org. In addition to selecting which specific material types a counselor should be able to send directly, you may also allow documents to be sent into Batch Acquire for manual processing by your staff. Each material type can be assigned a shared name.

• Batch Material (counselors only): There are four common document types that most institutions expect from counselors. Counselors have the ability to upload these four documents directly to a student profile in Slate.org to help eliminate the repetition of uploading the same document for each individual application. In addition to the application-specific documents configured in the Materials section described previously, your institution may choose the material types to which those documents should be directed (if your institution decides to accept them). The options include material types that you have configured in Slate as well as Batch Acquire for manual processing.