The following is an account of what occurs to synced fields when an organization has synced fields FROM their institution/organization INTO Via TRM AFTER an initial launch.
As background, fields in Via are initially synced into the Traveler Profile. These fields are synced from the organization upon traveler login and/or updated nightly depending on whether your University syncs via API or SFTP. Sync’d fields appear in Via as locked and read-only with a gray bar across the field data or the blank field and a lock icon. Synced fields are locked and read only to both administrators and travelers. Sync’d fields have ONE source of truth (in this case the organization’s Student Information System) and can never be edited in Via. In addition, neither travelers nor administrators can ADD data to sync’d fields that are ‘blank’. And, finally, neither the traveler nor the administrator can delete data coming from the Student Information System into Via.
To change any synced data in Via, the traveler or administrator must go to the source of the data (the Student Information System) and make the change there. When the Traveler logs in, any updated data in your Student Information System will ‘override’ any Traveler data in Via, including replacing filled out fields with ‘blanks’ (given the information had been removed from the Student Information System). The Traveler Profile data, in other words, is dynamic based on changing data in the organization’s system/s and logging into Via.
An Application for a syncing traveler turns on sync’d fields and retrieves that data from the traveler profile upon CREATING the application. The application continues to retrieve that data from the profile upon opening the application in the following statuses: Incomplete, Submitted, In Review, Waitlisted, Conditionally Accepted. This occurs whether the application is opened by an administrator or a traveler. The application does NOT continue to retrieve that data upon viewing the application in the following statuses: Accepted, Approved, Conditionally Approved, Nominated, Committed, Deferred, Withdrawn, Transferred, Not Accepted.
A Form for a syncing traveler turns on sync’d fields and retrieves that data from the traveler profile upon OPENING the form for the first time. The form continues to retrieve that data upon opening the form in the following statuses: Not Started, Started, Submitted and Accepted. This occurs whether the form is opened by an administrator or a traveler.
Because fields are determined to ‘sync’ upon CREATION of an application, an organization that launches Via and then subsequently launches their sync, will find that the applications created PRE-SYNC will have fields that are not synced and, therefore, are editable by travelers in the Incomplete status and are editable by administrators in any application status. Once sync is turned on for the account, and a previously created application or form is then opened, synced fields *may* pull data from profile, lock and become read-only. Whether or not this data pull/sync/lock happens depends on the application status.
Please refer to the charts below for further examples and clarification.
EXAMPLE 1: Application is started/created POST-SYNC
|
Sync Turned On |
Application Created/Viewed (after sync is turned on) |
Application Status as of October 1 |
Fields Appear Synced as of 10/1 on Application? (Y/N) |
Application Updating from TRAVELER INFO? |
|
Sept 1, 2020 |
October 1, 2020 |
Incomplete |
Yes |
Yes |
|
Sept 1, 2020 |
October 1, 2020 |
Submitted |
Yes |
Yes |
|
Sept 1, 2020 |
October 1, 2020 |
Accepted |
Yes |
No |
EXAMPLE 2: Application is started/created PRE-SYNC
|
Sync Turned On |
Application Created/Viewed (before sync is turned on) |
Application Status as of September 1 |
Fields Appear Synced as of 9/1/20 on Application? (Y/N) |
Application Updating from TRAVELER INFO? |
|
Sept 1, 2020 |
August 1, 2020 |
Incomplete |
Yes |
Yes |
|
Sept 1, 2020 |
August 1, 2020 |
Submitted |
Yes |
Yes |
|
Sept 1, 2020 |
August 1, 2020 |
Accepted |
No |
No |
NOTE: If sync is turned on in an account for certain fields first and then afterwards for others, each field will behave according to the rules documented above. So if, for example, an organization turns on the Date of Birth field POST sync, all applications in Accepted, Not Accepted, Approved, Conditionally Approved, Nominated, Committed, Deferred, Withdrawn and Waitlisted status that were started PRIOR to syncing that field will show that field as NOT synced and, therefore, is editable.