TUP Field and Prompt Cleanup for DPT Scholarship
- Helen Williams
Slate Instance | TUP |
Requestor/Reporter | Hannah Fridy |
TTS Staff | Helen Williams |
Date | 10/20/2023 |
Status | Complete |
Bug Description | Source format mapping for prerequisite courses had incorrect destinition field mapped in Slate for the entity. |
Issue Description:
When developing a query to use for scholarship review/decisionmaking for the DPT programs, the following issues were identified:
There are two fields in TUP for “family income level” which have been variously used in past cycles.
No data about Pell Grant status is being imported from PTCAS for 2024 cycle
The “millitary veteran status” field is incorrectly configured, resulting in the GUID displaying in query results.
There is no field containing “total observation hours” data for applicants.
Below are my notes for troubleshooting and testing to resolve these issues.
Family Income Level
The field containing data for the 2024 DPT applicants is “What was the income level of your family during the majority of your life from birth to age eighteen?” There is another field called “HRSA Family Income.”
HRSA Family Income is a bit field, meant to store the answer to the question “does your family income fall below the established guidelines” and
“what was the income level…” is a single value/prompt field.
Decided to just rename these fields so they would be less confusing:
HRSA Family Income > HRSA Family Income (Bit)
Does your family income… > HRSA Family Income (Value)
Pell Grant
The fieldname in the API source for PTCAS that holds this information is persInfo.custQues2.ques1979120.answerText and the possibly replies are Yes, No, and I Don’t Know
This is a similar configuration for the PTCAS question about “first generation” and is in the same section of the app wtih a lot of other questions already stored in the HRSA indicators field, so I think the best solution is to add a prompt value to the existing HRSA Indicators for “I received or was eligible to receive a Federal Pell Grant.” If the file out of PTCAS says “yes” this will be added to the HRSA Indicators, if it is no or I don’t know, it will not be added.
Updated the PTCAS Application (All CAS by Liaison - Applications) source format mapping and prompt value mapping on 10/20/2023 at 11:55 AM
To retroactively update the application records that have already been imported, I decided to export lists out of each PTCAS instance of only the applicants who said “yes” to the question in the application. I could’ve done a retroactive refresh in the source format but there have been so many files already and I also didn’t want to potentially cause issues (since some files are repeated multiple times). Probably it would’ve been OK, but didn’t want to chance it.
I created a single CSV file of all PTCAS applicants who answered “yes” to the Pell Grant question with their CAS ID and then I created a column for the Slate App ID by concatenating the CAS ID with the program ID for each program, to use for matching. After running this through test, I saw that it removed all other pre-existing values and replaced with the Pell Grant answer. After doing some digging, found that this setting is on the field:
Given what I found with the MVS (below) and messing with these field settings, I didn’t want to just change the setting now (although I did try it in test quickly and it did not seem to break anything or delete data as I experienced below).
Instead, I took the list I had of applicants who answered “Yes” to the Pell Grant question w/their Slate App ID and made a CJ query with the applications query base, then added a filter for App ID and pasted in a comma separated list of all 85 IDs. I then ran the query and used the Output tool for Field to add the pell grant prompt to the existing values for these applications (I did do this in Test first to make sure it worked, and it did). The only downside is this forced the records to go through the rules, but as these are all apps in an active period, that isn’t terrible.
Military Veteran Status Fix
This field has been incorrectly configured for several years? It is meant to store the Prompt ID, however in the (depracated) field editor it is currently set as “Single Value.” This seems to have translated into “custom configuration” when Slate introduced the new Field Editor tool.
This appears to be the reason that the export/filter options for this field in Configurable Joins queries is not working properly.
In our test environment I attempted two fixes:
Use the (new) Field Editor tool to change the settings to Prompt ID
Use the (deprecated) Feild Editor tool to change the Value = Prompt ID
After making the change to the feild editor, I refreshed the configurable joins library and attempted to export the value in a CJ query; there were 1608 application records where this field had a value before doing this, and after I got 0 records.
Therefore, to fix this I needed to:
Generate a CSV file containing the Slate Person ID, Slate Application ID, and Military Veteran Status for all records that had data in the MVS field
Fix the field settings in the Field Editor tool, force refresh the cached field data, then force refresh the configurable joins library
Use the CAS Application Cleanup Source Format to import the data back into the MVS field
I did the above process in the Test environment to ensure it worked properly, and it appears to have done so.
I checked one person record per possible value in the MVS field to ensure the mapping was correct and also checked 4 sample person records with more than one application to ensure all app fields were updated correctly.
I also checked the current CAS source format to ensure that none of the mapping was changed or removed, and the mapping to Veteran Status was still there.
Observation Hours
Total Observation hours could technically be calculated within the CJ query (which I showed Hannah how to do) but given how often it may need to be referenced, we decided it was best to revive an older field for “Observation Hours” and set up a rule in Slate to calculate the total based on the data in the Experiences table/entity. I’ve set up the rule and retroactively run it against the 2024 applicants so you can how export “Observation Hours” in a query and get a value without having to make it fancy in the CJ query.