Coalition Source Formats: Application Profile
  • 01 Aug 2024
  • 6 minute read
  • Dark
    Light
  • PDF

Coalition Source Formats: Application Profile

  • Dark
    Light
  • PDF

Article summary

This source format is loaded into the databases of all Coalition members and many of its source fields are pre-mapped to standard destinations within Slate.

Source format requirements

Remap settings are customizable, with the following exceptions:

Mapped application round

An application round must be mapped to create an application. This may be mapped from the Application Round source field, with the appropriate Prompt Value Mappings configured, or it may be mapped as a Static Value if all applications should be created in the same round.

🔔 Important! Do not change coalitionID or scoir_id.

The fields Coalition Application ID and Scoir ID are both used to facilitate the integration. These mappings should remain unchanged.

IDs_that_must_not_be_changed_-_coalitionID_and_scoir_ID.png

Applications should be imported as unsubmitted.

Since the supplement form isn't yet completed by the applicant at the time of import, the submitted flag is purposely not mapped. The submitted flag is included on the supplement form instead. Positioning this status change at the submission of the supplement form allows Scoir to display an incomplete status to applicants when they view their Scoir profiles.

Configuring the source format

To configure the CoalitionApplicationProfile source format:

  1. From the main navigation, select Database, then select Source Formats.

  2. Select CoalitionApplicationProfile (JSON).

  3. Click Remap.

  4. Map additional items and make any desired changes in Field Mappings page.

  5. On the right, click Prompt Value Mappings.

  6. Map values as needed:

    • The full list of values that may be included in the source data are in the Application Profile Guide from Scoir. Request access to the guide here.

    • You may use Append Values to map the possible source values prior to receiving them in the data.

    • The application_round source field will contain the values configured in Scoir by your institution. See the section Application Round Considerations for more information.

  7. Add Field Fusions and Static Mappings as needed.

  8. With remapping completed, return to the CoalitionApplicationProfile source format page using the breadcrumb navigation. 

  9. On the right, click Edit.

  10. Set Remap Active to Active. 

  11. Click Save.

    Set_Remap_Active_to_Active.png

Important!

The following source format settings should not be updated:

  • Unsafe (Unsafe): Setting the source format to unsafe allows the import to update the necessary fields even if an application exists.

  • Type (One-Time / Differential): This setting retains each source as new sources come in. Since an application is sent one time, changing this setting to Cumulative will degrade the integration and could result in data loss.

  • Callback URL: This setting allows Slate to notify Scoir when the application creation has completed.

  • Format Definitions: As a standard source format, format definitions are inherited. Updating the settings on the Format Definition tab will result in the inherited settings to be overridden and will degrade the integration.

  • Import Automations: The data sent from Scoir is automated through the integration, so there is no need to adjust any settings on the Import Automation tab.

Application Round Considerations

Every application in Slate must have an application round. This data point must be mapped in the source format to ensure that an application is created.

How Scoir Application Rounds Relate to Rounds in Slate

Since your institution can configure which round options applicants can select within Scoir, the rounds should directly match your institution's round configurations within Slate in most circumstances.

If your application rounds have a specific entry term (for example, Fall and Spring), you can map the source format's same application_round source field to an entry term field (if you have one) as a second destination. Then, on the Prompt Value Mappings page, set the fall round to the fall entry term value, and the spring round to the spring entry term.

If your application rounds are complicated and determined by multiple factors, the application round set by the import can be preliminary. Use the application_round source field to place the applications into the likely round for most situations. The Coalition Supplement form is capable of updating the application round, and this field can be configured with conditional logic and calculation formulas as necessary.

Default and Override Behaviors for Application Creation

By default, Slate will match onto an existing application in the same mapped application round that exists on the same person record. If an application in that round does not exist on the person record, a new application will be created for that record.

There are three possible override options for this behavior:

  1. Always create a new application. Slate's default behavior, rather than create an additional application in the same round, instead attempts to match onto the existing application. To force Slate to create a new application instead, map a new static value:

    • Destination: Application Fields; App: Round Always Create

    • Value: Yes

Static_Mapping_-_Application_Fields__App-_Round_Always_Create.png

  1. Always use the existing application (in an active application period). Slate's default behavior only matches onto the existing application if the mapped application round matches the round of the existing application. To force Slate to match onto an existing application in the active application period if one already exists for the record, map a new static value:

    • Destination: Application Fields; App: Round Use Existing

    • Value: Yes 

    Note: This method will not update the  round on the existing application. To use the existing application while also updating the round, use the next override option.

Static_Mapping_-_Application_Rounds__App-_Round_Use_Existing.png

  1. Always use the existing application (in an active application period) and update the round. This option is nearly identical to the previous option, with the exception that it also updates the application round to the one mapped in the import. To force Slate to match onto an existing application in the active application period if one already exists for the record while also updating the round to the value mapped in the import, map a new static value:

    • Destination: Application Fields; App: Round Use Existing and Update

    • Value: Yes

Static_Mapping_-_Application_Rounds__App-_Round_Use_Existing_and_Update.png

More information on these three override options can be found here.

Mapping Fee Waivers

If your institution has an application fee, it is important to map the Coalition fee waiver fields so the Coalition Supplement form can reference them when determining if a fee should be charged. The Coalition Supplement Form article in this section discusses the use of this field to prevent the accidental charging of an application fee.

The Coalition fee waiver includes:

  • Qualifying for the Federal Free and Reduced Lunch Program:

    • cfw_free_reduced_lunch_yn

    • Receiving a College Board, ACT, and/or NACAC fee waiver:

      • cfw_college_board_waiver_yn

      • cfw_act_waiver_yn

      • cfw_nacac_waiver_yn

    • Being eligible for a Pell Grant:

      • cfw_pell_grant_yn

    • Participating in TRIO programs:

      • cfw_participate_trio_program_yn

    • The application will also continue to support the Armed Forces Fee Waiver, which institutions can configure in their Application Settings in Scoir.

Bit, or Multiple?

Depending on your institutional needs, you may choose to map these data points differently. The two most common options include:

  • A single application-scoped fee waiver field that uses a bit prompt. The application stores Yes if any of these fee waiver conditions are met. This may be useful if your institution only needs to capture whether the application is eligible for a fee waiver, but the specific details aren't necessary.

  • A single application-scoped fee waiver field that stores multiple prompt values for each waiver eligibility. This option includes prompts for each fee waiver type.

Tip

You do not need to create a new field to capture this data if you already have one that you can use. If you do create a new field, save a step in the later form configuration by using the field ID app_fee_waiver.

Setting up the fee waiver mappings

Whether using a bit prompt or multiple prompts, each of the Coalition fee waiver fields should be mapped to your fee waiver field. The differences between these mappings take place exclusively on the Prompt Value Mappings page.

Prompt_Value_Mappings_Page.png

If you are using a bit prompt for the fee waiver field:

For each of the Coalition Fee Waiver fields, map the true source value to Yes, and leave the false source value unmapped.  Any true value in the Coalition fee waiver fields will set your fee waiver field to Yes.

Coalition_Fee_Waiver_fields_-_Bit.png

If you are storing multiple prompt values in the fee waiver field:

Map the true source value for each of the Coalition Fee Waiver fields to the associated prompt value, and leave the false source value unmapped.  Each true value will set the corresponding prompt value on the field.

Coalition_Fee_Waiver_fields_-_Multiple.png

 

Next, we'll talk about the Coalition Supplement form.

Have questions? Check out the Coalition FAQ article.


Was this article helpful?