Visitor Aware | Singlewire Software

SourcedIds

When syncing data, either via OneRoster API or SFTP files, any data that requires the SourcedId field must treat this field as immutable. This is because many Visitor Aware data imports utilize the OneRoster Data Specification.

According to the OneRoster Specification:

"The sourcedId attribute is used to provide the unique identification of the associated object between the communicating end-systems. Ideally, these should be globally unique identifiers (the internal format/structure is an implementation dependent issue and NOT constrained to a form of Universal Unique Identifier, UUID).

[...]

If an object has been deleted then the associated sourcedId' MUST NOT be reassigned to another object. Therefore, once a sourcedId has been assigned it is permanently allocated to the associated object and so can be used to recover 'deleted' data."

What if my SourcedIds change or I switch Student Information System (SIS) providers?

Data utilizing your original set of SourcedIds must be deleted before implementing the next set of data that ties to a new format of SourcedIds. If data is not removed and primed before the new SourcedIds, users run the risk of having a full set of duplicate data. This can reduce profile matching and accuracy of Visitor Aware in identifying visitors, students, and staff utilizing the system.

Please follow these steps to ensure your Visitor Aware client is cleared of the old SourcedIds:

1. Turn off the connection to ensure data from the old system is not continuing to sync.
   • OneRoster API Connection: Navigate to System Settings > Integration Management > OneRoster Connection, on the setting "Connection Active?" select the "No" radio button, then click Save.
   • SFTP Connection: From your SIS, stop any automated imports that run on a daily basis.
2. Navigate to System Settings > Data Management > Clear records. Clear all Student Records and Visitor/Volunteer/Guardian records.
3. Submit a support ticket for a support agent to flush all users with logins who were imported with SourcedIds
4. Reinstate the connection to the new SIS provider.
   • OneRoster API Connection: Navigate to System Settings > Integration Management > OneRoster Connection and reconfigure your OneRoster API Connection (steps here).
   • SFTP Connection: 
     • Do not resume automated imports. One of our Support engineers will need to review the export data to ensure it still meets our formatting standards. 
     • Instead, please submit a support ticket and request a support engineer to review your new files.
5. Once you know the new Org SourcedIds for your school orgs, navigate to System Settings > Location Management > All Locations, edit a location, scroll down to the "Select a School" option at the bottom of this page, and update the Org SourcedIds listed to match the new Id.
   Note: Repeat the process in Step 3 for each location.

OneRoster API and SFTP

Visitor Aware can consume your OneRoster or direct data using SFTP, with the following restrictions:

1. If using a OneRoster API connection, Visitor Aware only allows files to be sent via SFTP that contain data that is not part of the OneRoster specification.  Specifically:
   • Cannot Pickup
   • Location Destinations
   • Volunteers
   • Volunteer Opportunities
   • Court Orders
   • Employees
   • Deactivated Employees
   • Bussing Information
2. If using an SFTP connection, Visitor Aware will not supplement data from a OneRoster API connection, and will only consume files listed on the Import Resources page.  If you still need to send OneRoster data, you may do so via SFTP by referencing the OneRoster.zip file, however...
   • If sending OneRoster.zip, we do not accept any other student, visitor, or user files as they conflict with the OneRoster data sets.

Why Can't I Use Both?

Due to data override issues between data-sets and formats, we do not support both SFTP and OneRoster API connections concurrently as it applies to any OneRoster compatible data, and introduces a lengthly list of issues and reduces the integrity of your data.

For example 

• Consuming a OneRoster API that has students, AND a visitors.csv (or any visitor import template) file that references student relationships and/or can/cannot pickup information results in the following:
  • The OneRoster API data set will always take precedence
  • All guardians will be flagged as an approved pickup (regardless of what the SFTP file says)
  • Any guardian relationships that are present in the OneRoster API but are not present in the SFTP file are removed  
• Consuming a users.csv via SFTP, AND a OneRoster API connection that has users present, the following will occur:
  • Any user that is present in both the csv, and the OneRoster API will be modified by the data set retrieved most recently
  • Any user in the csv that is (for example) an Administrator but is a Teacher in the OneRoster API will end up as a teacher, and will not be able to access administrative functionality within Visitor Aware
  • Any deactivated users in the users.csv that are marked as active in the OneRoster API will end up as active users, and vice versa

What if I use both?

Either contact your SIS administrator to properly provision your OneRoster API data sets, or contact your SIS administrator to generate full data sets based on our SFTP import templates.