Mapping Your Application Source Formats

Last updated
Save as PDF

Slate has pre-mapped many common fields in the Source Formats that are the same across every instance of Slate. Custom Slate fields will need to be mapped as they are unique to your instance. For more information, visit the Application Source Format sections of the Slate Knowledge Base.

All updates to the Source Format mappings should be done in Slate Production while the Source Format Remap Status is inactive.

Updating Your Source Format Mappings

To view the pre-mapped fields and make updates to the Source Format mappings, you need to retrieve a file from the CAS API. There are two approaches to retrieving a file:

Set up your subscriptions. If the subscriptions were directing files to Slate Test, download the file from Slate Test and manually upload it to the Source Format in Slate Production. You can download the file from Slate Test from the SFTP Explorer or the Source Format.
Manually work through the on-demand pattern to export a CSV file from the CAS API and manually upload it to the Source Format in Slate.

Retrieve the application form ID and organization ID:

GET {{baseUrl}}/v1/accounts/info

Retrieve the program ID and application ID:

GET {{baseUrl}}/v1/applicationForms/{{applicationFormID}}/organizations/{{organizationID}}/applications?expand=selectedPrograms

Download application file:

GET {{baseUrl}}/v2/applicationForms/{{applicationFormID}}/organizations/{{organizationID}}/programs/{{programId}}/applications/{{applicationId}}?expand=all&includeNulls=True

Once the file is uploaded, and Slate processes the file, you will be able to verify and adjust the mappings as needed.

There may be pre-mapped fields that do not appear in the Source Format, even if your file includes nulls. For example, there are five schools and three self-reported test scores pre-mapped in the Source Format. The mappings will only be visible if the datapoint existed in a recent file. If your initial file only included three schools, then the mappings for schools four and five will not be visible. To map or unmap fields that do not appear in the Source Format, you may create a CSV file with the CAS API fields as the column headers, mimicking a file, and manually upload it to the Source Format. Note that there must be at least two column headers for the file to process successfully.

Round Mapping

Round is the only required, additional mapping to create an application in Slate. If your Round is always the same cycle to cycle, it can be set as a static mapping. If your Round is tied to a period of time or other datapoint that may change, we recommend mapping to a field.

Additionally, we recommend a static mapping of Round Always Create to prevent application data from multiple designations from overwriting. See the Slate Knowledge Base for more information about how applications are imported.

Unique identifiers for matching

Slate automatically creates three new fields in an overnight process after you import the standard Source Formats and set them as "unique for merging." The standard Source Formats map CAS IDs into these fields to ensure proper person-scoped and application-scoped matching for incoming CAS application data and documents.

Person-scoped: "CAS/Liaison Person ID"
Application-scoped: "CAS/Liaison Application ID"
School-scoped: "CAS/Liaison School ID"

These fields are pre-mapped in the Applications Source Format and should not be adjusted.

Program Information

The values set in the CAS program properties when configuring your CAS programs are valuable for properly coding incoming applications to the right major, degree, start term, delivery, and more. Different schools use these CAS program properties in different ways, making it impossible to pre-map most of these properties. Review the program properties available against your CAS program configuration strategy to determine which properties to map.

Often, to map start term, schools create a field fusion of progMate.progSele.startTerm and progMate.progSele.academicYear. For more information about field fusions, see the Slate Knowledge Base.

CAS Custom Questions Specific to Your Programs

If you've configured custom questions to ask applicants to your CAS programs, you'll need to map those. There's such a great variety of custom questions asked that it isn't possible to pre-map these questions for import into Slate. By default, the CAS custom questions will have headers containing the ID of the custom question itself. One of the values delivered is the question text itself, so you can use that to determine which ID goes with which question.

You can find the custom questions when remapping your Source Format by entering the following search term:
"progMate.progSele0.custQues"

Generally, you'll want to map the "answerText" column, as that will contain the applicant's response.
Alternatively, you may want to map the "exportCode" column. You should only map this field if you've configured Export Codes for your custom questions in CAS. When configuring custom questions in your CAS programs, certain question types (multiple choice, drop down) present the option to define Export Codes for the response options you make available for applicants to select. These Export Codes are a useful tool for making value mappings easier. For example, if you asked a question, "What's your t-shirt size?", you might have 3 response options with the associated Export Codes: "Small" - "S", "Medium" - "M", "Large" - "L".

Internal Question Labels

With the Internal Question Label feature, you can define a short, easy-to-understand label for any custom questions you create in the Program Materials (Fourth Quadrant) section. As you create custom questions in the Configuration Portal, you'll have the option to add an Internal Question Label. Whatever value you type into that field will be delivered as the column header in the file delivered by the CAS API to Slate. For example, if a custom question asks, "What is your favorite color?", you could assign an Internal Question Label of "favorite_color", and applicants' responses to that question would be delivered to Slate by the CAS API with "favorite_color" as the source field.

When creating Internal Question Labels, consider the following:

Keep the Internal Question Label short. Slate limits headers to 60 characters.
Make sure the Internal Question Label is descriptive. Other people should have a good idea of what information it contains, so avoid acronyms and abbreviations. You may want to use the Slate Field ID to align with your existing naming conventions.

A powerful feature of the Internal Question Label is that it is retained across environments (from prelaunch to production) and cycles (from a past cycle to a future cycle). That means that you can define Internal Question Labels in the prelaunch environment, configure your Slate Source Format mappings, test your integration, and confidently turn it on in the production environment with no additional mapping work required. Furthermore, when cycle rollover time comes along, if you keep your questions the same, you won't need to do any new mapping work to accommodate the new cycle's application data because the questions will continue to be delivered with the same Internal Question Label.

Export Codes, if defined, will be delivered in a column with the word "_code" appended to the header. For example, if a question has the internal question label "favorite_color", the Export Code would be delivered in a column with the header "favorite_color_code". You can choose whether to map the Export Code or the answer text.

Things to Consider

When mapping your data, there are other things important to consider.

Slate-Delivered Fields

Sex: by default, the Slate-delivered field has the options Male and Female. This prompt list may be modified.
Major: by default, the Slate-delivered field is a text box field. This can be changed to a prompt list. You can only access the Major 2 and Minor fields if Major is changed to a prompt-based field.

Review the Slate documentation about standard fields for more information.

Null Handling

If you are importing data for optional fields more than once (e.g., application updated and submitted events), then it is important to enable custom null handling when mapping the field in the Source Format. Checking the box directs Slate to erase any previous data if the field is blank in a future import. If this box is not checked, previously entered applicant data would remain in Slate even after the applicant deleted the information from CAS. Null handling only needs to be enabled for optional questions since required questions must have a response.

For more information, also see the Slate Knowledge Base.

Multi-Select Fields

Multi-Select fields will be indexed and you need to map each possible response. In a test application, select all possible responses to have visibility over all fields needing mapping. For example, if the internal question label is “membership” and there are four possible responses, you will need to map the fields: membership, membership-1, membership-2, membership-3.

Recommendations

Imported recommendations are a different material type than the Slate-hosted recommendation forms. Slate outlines best practices for recommendation materials and checklist items in the Knowledge Base. If metadata is desired, custom fields should be created.

Test Scores

Official test scores and self-reported test scores may be sent through the CAS API. Official test scores can be identified with the source field string “acadHist.test.offi.”. Self-reported test scores can be identified with the string “acadHist.test.repo.”.

If official test scores are imported, make sure to add a static mapping of Verified for each official test type. For additional information about importing test scores, refer to the Slate Knowledge Base.