Importing Decision Data
- 16 Nov 2023
- 4 minute read
- Print
- DarkLight
- PDF
Importing Decision Data
- Updated 16 Nov 2023
- 4 minute read
- Print
- DarkLight
- PDF
Article Summary
Share feedback
Thanks for sharing your feedback!
Decision Data Import File
Slate supports the importing of decision data from an external system. Exporting decision data from an external system is similar to, and dependent on, application data, as detailed in Importing Current Applicant Data. Importing decision data should be a distinct import that does not include other new qualitative data at the same time.
While decisions can also be imported as Interactions, this documentation addresses importing them as actual decisions on the student application, which correspond to Slate decision codes and the ability to release them later if desired. Consult the Decision Codes documentation for standard recommended codes.
Important
Each decision must be exported from an external system as a unique data row. While multiple decisions per applicant can be imported in one file, each decision row must have a corresponding Unique ID, Decision Code, and Date. This allows decisions to be stored chronologically on the applicant record.
The decision data file should include the following data fields (additional data points are optional):
Header | Description |
|---|---|
Unique App ID | Use the 9-digit Slate Application Ref ID for matching on the appropriate application record. If your application-scoped unique external ID is stored in Slate it may alternatively be used to match onto the application record. |
Decision Code | At a minimum, codes from the external system will be mapped to a Slate decision code. If you have codes that serve as Slate decision reasons, those can be mapped to a different destination in Slate. Use of decision reasons when importing is optional. Often there are numerous external decisions that do not need a Slate equivalent. If using the decision code is important for administrative reasons, it may be mapped. |
Confirmed Date | Date format is flexible for import but should include month, day, and year. The date will be mapped to the Confirmed Date in Slate. Without the date mapping, a decision will be imported with a Provisional status in Slate, which can create barriers to further updates or decision release. |
A sample file layout with four applicants who have a varying number and type of decisions would contain values similar to this:
AppID | Decision Code | Confirmed Date |
123456789 | Admit | 2019-02-01 |
123456789 | Admit/Matric | 2019-02-18 |
987654321 | Admit | 2019-02-01 |
987654321 | Admit/Decline | 2019-03-29 |
564231897 | Deny | 2019-01-22 |
789123456 | Waitlist | 2018-12-12 |
789123456 | Waitlist/Accept | 2019-3-01 |
Important
Additional, different decisions may be added to an applicant record over multiple imports. However, it is not possible to update an imported decision after the fact, such as with an amended date. Likewise, it is not possible to add a second decision of the same code in a subsequent import. These adjustments need to be done manually on the record.
Value Mappings
Use the lists in the destination value column to define the value mappings.
Source Value | Destination Value (Application) |
|---|---|
AppID | App: Application Slate ID Matching Only |
Decision | Decision: Code |
Date | Decision: Confirmed Date |
If a Unique Application ID cannot be included in the source file, it will be necessary to include another Unique ID for matching on the person record. If a Person-scoped ID is used for matching, the data mappings must also include Application Round, so that Slate can identify the application to which the decision is added.
Tip
Consider timing the import of external/historical decisions into production when it is not distracting to have this volume of additional decisions "cluttering" the release decisions interface for one month.
Releasing Imported Decisions
Decisions cannot be released with an import. This is intentional, since there are many checks and balances needed in the decision release process. Imported decisions can be released via the Decision Release module only for:
Decisions on applications that are in an active period
Historical decisions created by import within the prior 30 days, after which they are unavailable in the Awaiting Release Queue
Important
Decisions imported to an active period can be released without notifying the student if no letter is associated with the decision code, and the Default for Decision letter setting is selected.
If there is a letter associated with the decision codes, the student is notified through the status update system message, and the letter would be visible on the Student Status Portal page. If a status update message has not been configured, the message is not released. However, if the student has access to their status portal, they will see the letter you are releasing if it is associated with a code.
Consult the Decision Notification Status Update documentation to review all of the conditions that must be met in order for a decision notification to be sent.
Similarly, if you have a custom email that filters based on a decision code, be sure to check your active mailings and be sure that none will send to this population.
Best Practice
For historical applications, allowed imported decisions to idle for 30 days after import so that they fall out of the Awaiting Release queue in the Release Decisions Tool.
If historical applications are released in Slate, the release date must be set to a current or future date (not a past date, which may create an unreliable data point for reporting). By not releasing, the imported decisions have Confirmed as their terminal status, and the confirmed date can be relied upon as historically accurate.
Should you determine the need to release historical applications before the 30 day mark, you can activate the round and period, release the decisions, and then inactivate the round and period again. Another option is to manually release them from each student record.
Was this article helpful?
