CAS API PTCAS In Progress File Missing

Issue Description

Periodically in September and October 2023, admissions staff have found that applicants in PTCAS who are verified and should be complete do not have Slate records.

Upon investigation, the issue is that no “in progress” subscription file was sent via the API for these students, which is where the application record is created in Slate. It appears that the in progress files should have been sent at the beginning of the cycle (August 2023) but were not.

After extensive research and various hypothesis, ultimately I found that we were not getting these IP files most of the time because students are given the opportunity to elect not to share IP data with schools. The students who select this option will never have an IP data file sent. There are other scenarios where this would happen, such as when a student began an application to one program but submitted an application to a different program, or when there were issues with the IP file sending process (SFTP down, etc.).

Ultimately, the core problem is that the application source format does not have the configurations needed to create an application when the first file that is sent is an appliation file (and not an IP file). The source format needs to be updated to map to a round and add a static mapping of “round always create = yes.”

Troubleshooting/Research

Key Learnings

1. Retroactive refreshing a file in a source format will only update the records it has already matched; it does not try to rematch. When testing a source format matching behavior, you must upload a fresh file each time.

2. The way matching criteria work for application data and person data; initially it seemed to me that if Slate was comparing a source with value A in an application-scoped, unique custom field to the record that had value B in that field (so no match), Slate was just overriding value B with value A. That’s not exactly what happens… when there is no match using application data, then Slate moves on to matching using person data. At that stage, where no app data has matched but Slate can match on person, and an application in that round already exists, Slate matches to that existing app, and then replaces value B with value A. https://knowledge.technolutions.com/hc/en-us/community/posts/4407213522075-App-import-overwriting-previous-app-regardless-of-settings

3. Applicants who select “no” in WebAdMIT/CAS for the option to release their information to schools before submitting will not have an in progress data file sent as part of the API. The first file we get will be when they submit and through the application source format.

Research

10/19/2023 the following list was provided by the DPT admissions team of records that they identified as verified in the DPT-BOS instance of PTCAS but which had no Slate application record.

Troubleshooting

I created the following query to identify person records which were in the CAS - Application source format but which did not have applications to any of the DPT programs. It generates a row for each person record and indicates what program they have applied to by checking the source file name for the CAS Program ID for each DPT program.

https://tusmgp.admissions.tufts.edu/manage/query/query?id=6dc671d3-c44c-437e-99f0-c0baf163feed

There were these six students from Boston (above), plus two additional, and some of them had applications for more than one program.

I need to determine if we are not getting certain in progress files, and if so why. Or if the issue is that there were some in progress files missed during the API setup process, which is why we do not have them now. If it is the latter, then an audit of the in progress files in Slate vs. PTCAS should show in progress applicants in PTCAS that are not in Slate.

• Export a list from Slate of all in progress applicants for the 2024 cycle, including CAS ID for matching.

• Export a list from PTCAS of all in progress applicants for the 2024 cycle.

• Compare the two lists to determine if there are applicant records in PTCAS for in progress that are not currently in Slate.

In Progress WebAdMIT vs. Slate

11/15/2023: I ran a spreadsheet out of WebAdMIT for each instance, and then compared the CAS IDs from the WA list of in progress to what applications existed in Slate. For each instance, these were the results:

BOS: 25 in progress apps in WA that were not in Slate. Dates of designation added ranged from 6/15 - 8/25, with the most occuring in between 6/15 - 6/28.

PHX: 14 in progress apps in WA that were not in Slate, dates ranged from 6/15 - 8/25.

SEA: 12 in progress apps in WA that were not in Slate. Dates ranged from 6/15 - 8/18.

Spreadsheet compiling all missing in progress apps across programs:

• 

  15 Nov 2023, 11:34 AM

PTCAS-app-started_<instanceId><organizationId><programId><applicationId><casApplicantId>.csv

BOS: PTCAS-app-started_6861_12748_349019_

Application Matching Issues

[3:58 PM] Williams, Helen

So I have two source formats -- one for in progress files and one for application files. In progress consumes the initial application data file, and includes Round: Always Create. The application source format does not include Round: Always Create because it is supposed to just match and it will get at least 3 data files for every application and therefore it cannot be creating a new application every time. 

[4:01 PM] Williams, Helen

This student had an application file come through the IP source format for BOS on 11/15. That created the BOS application, with a BOS app ID. On 11/26, the same student had an application data file come through when she submitted to SEA, so it went through the app source format. The app source format couldn't match on the ID, but also isn't set to round always create, so it overwrote the app ID with the SEA ID (but kept the program = BOS). Then, when I tried to upload the SEA app through the IP source format, it matched to the SEA ID (which should've been the BOS ID, but wasn't) and overwrote the data again.

[4:02 PM] Williams, Helen

I should've looked at the app ID and not just the program field, but also I think this part (having a submitted app to one program without an IP app, but an IP app for a different program) is the final mystery of WTF has been going on with these applications

To fix the issue in the short term, I put all the application files through the API In Progress source format to create the applications, and then I refreshed the existing files to update them to their current status of verified. Overnight Slate should run the rules and match all the documents, so tomorrow morning these should be in good shape for you to finish them up and get them ready for review.

11/15/2023

​Emoji :white_check_mark:✅ Benson, Bailey 2283360939 14400572 Looks like same issue with no IP file

​Emoji :white_check_mark:✅ Nekrasova, Anastasia 6381531350 app ID: 14328303Looks like same issue with no IP file

​Emoji :white_check_mark:✅ Moen, Kailey 988176475 5485667558 - has verified BOS app, is in Slate with only PHX and SEA app 14477459 Looks like had IP file for SEA and PHX, but not BOS. App file was sent for BOS on 11/8, but didn’t go anywhere.

Rocha-Heijenga, Sylvia Gia 539972316 - verified BOS app, in Slate as awaiting submission in BOS 14386948

Resolution Steps

Short-Term Fix

To catch when a student is missing an in progress application file but later submits their application in the CAS system, the DPT admissions team uses this query:

https://tusmgp.admissions.tufts.edu/manage/query/query?id=6dc671d3-c44c-437e-99f0-c0baf163feed

If a record is found, the following steps can be taken to resolve this issue for this student:

1. Go to the student record in Slate, Timeline > Interactions, then filter to “Source.” Review the source files to see what files have been sent by the API. Review the file name to determine which program(s) are sending data (349019 is BOS, 349022 is SEA, and 349027 is PHX):

   

2a. If only one program is sending data, then skip to step 3.

2b. If more than one program is sending data, or if there are applications in the 2024 round for DPT already, review the information in the Application Details (PTCAS) tab in the application record to ensure that the program ID and application ID use the correct code to correlate to the correct program.

If they do, go to step 3. If they don’t, then edit the application record to change the program ID and application ID to use the correct program code.

3. Use the instructions for obtaining a single application file from Postman to get a copy of the application you are missing from the correct CAS environment. This will be a file containing all the “live” application data, but we will treat it as if it was the file sent by the API. Save the file as a CSV using the following naming convention, saving one as the IP File and one as the App file, and replacing the information between <> with the correct ID from the record.

4. Once you have the files saved, go to Slate > Database > Source Formats > PTCAS In Progress (…) > Upload File(s) and upload the IP file through the source format. After uploading, go to Database > Force Process Import and run to import the data immediately.

5. Go back to Source Formats > PTCAS Application (…) > Upload Files and upload the App file through this source format. (This process is used instead of doing a retroactive refresh against the source that was sent by the API because when an application has more than one application record, the retroactive refresh has caused issues, it seems better to just do a direct upload through the full source format than to do retroactive refreshes).

6. Now rules will run against the record, and overnight any documents pending import that had been sent by the API will append to the record/application.

Long-Term Fix

Best solution for this is that the application source format needs to have “round always create” mapped in the static mappings (and also some other mappings required for the app data). This should only create a new round when the ID doesn’t match, but need to test.

https://knowledge.technolutions.com/hc/en-us/community/posts/4407213522075-App-import-overwriting-previous-app-regardless-of-settings

Testing

1. Change the settings to the source format to add Round: DPT and Round Always Create: Yes.

2. Generate an application data file and put it through the import process. (Do not retro refresh original file, as retro refresh does not attempt to re-match).

3. Confirm that new application created.

4. All testing scenarios ran 3/1 and 3/4, confirmed no issues on 3/4 and will update in production.

Scenarios:

1. Student has no history of an in-progress data file because they did not indicate they wanted to share this information. They submit their application and an application data file is sent to us, but does not match because of current settings and does not create an application.

   1. Find a student who has no application. Create an application file to import via the app source format as submitted.

   2. Luis Carrillo had file sent to app source format but no history of file sent to in progress source format. Original file created a person record but did not create an application record. In Test I uploaded a new file through the app source format and confirmed that it did create the application correctly.

   3. Just in case, tested the scenario where no person record existed at all by modifying an existing data file to change all the data used for matching (CAS ID, first name, last name, email) to make it look brand new and confirmed that Slate did create a new person record as well as the applciation record as expected.

2. Student has an in-progress application for more than one program, and submits the application for one of those two programs. Slate should match on the existing application ID and update only the app for one program and not the other.

   1. Kaiden Andersen had an IP app for PHX and SEA. Uploaded an app file for PHX through the app source format and confirmed that PHX app was updated (PHX changed to submitted, SEA still unsubmitted). Source file didn’t change the CAS status (wasn’t changed in file itself), so was still In Progress. This prevented the checklist from being added, and screwed up the status rules, so going to try again with another file and change status so that it will function.

   2. Phillip VanWanzeele had an IP app for PHX and SEA. Changed csv file progMate.progSele0.submissionStatus from IP to Received before uploading; this time the checklist was added and the status updated to Awaiting Materials appropriately.

3. Student has an in-progress application for one program, but then submits an application for a different program. Slate will not match on app-data, but will match on person data, and so will match the app data in the source to the application record in the same round on the person record.

   1. Find a student who has an IP app and no other apps. Create an application file, modify so the program data is different, import via the app source format as submitted.

   2. Jade McIntyre had an IP PHX app and no other apps. Modified the csv file to change the Program ID to -022 instead of -027 (SEA instead of PHX) and the status to Complete. Uploaded through the app source format and it did create a SEA ap, change the status to complete (which triggered checklist and status update).

4. Student has an existing applciation for one program and an update file for the same application is sent later, Slate should match and not create a new application.

   1. Find a student who has an application and do a second import of the application data file after changing the app source format to ensure a second app is not created.

   2. Andrew Rattray had an IP PHX application. Changed source file to update the status to Verified and then imported through the application source format. Confirmed that no new app was created but existing app was updated correctly.

Add to App Source Format:

progMate.progSele0.programID = CAS/Liaison Application Program ID, Application Details - Program, and Inquiry Details - Location Interest

progMate.progSele0.startTerm = Start Term/Year, Inquiry Details Planned Entry Term

Fields to change to prevent matching entirely:

CAS/Liaision Person ID

First Name

Last Name

Email

DOB