|Overview||Importing This File|
|Video Explaining This File||Products That Use This File|
|Populating This File||Next: Organizational Units|
Accounts must be established for all users – both those who will be actively logging into Campus Labs products and those about which data will be collected. The accounts data sets define users, connect them to each other, and provide additional information. The Accounts file is used in some form by almost all Campus Labs products. A blank template can be downloaded from your Campus Labs Data Management site.
Errors can wreak havoc on Campus Labs data, so it is critical that it is correct. If bad accounts are loaded, a considerable amount of work must go into mapping and deactivating accounts.
Accounts can include students enrolled in classes, instructors teaching those classes, and advisors and other staff who will be using the products. The PersonIdentifier defined here is referenced in other files. The extraction logic used in these other files must be mimicked in the Accounts file to ensure that all necessary accounts are created. For example, if advisors are added for the Beacon Managed Connections, those same advisors must be added here for accounts.
This file typically requires multiple unioned queries, one for each type of user (faculty, students, etc.).
The most critical thing with Accounts is that the PersonIdentifier must be in the SIS somewhere, and it must match the identifier chosen during the authentication process. While it may seem easier to create the Account file out of the authentication system on campus, this does not work for the other files that require the PersonIdentifier. If the PersonIdentifier cannot be found in the SIS, it will need to be added or a lookup table must be created before moving forward.
Assess what types of emails are stored in the SIS and decide which email will be brought over to Campus Labs. Consider whether different formats are used for faculty and staff emails and build the script logic to account for these differences.
Accounts records without emails fail on import. Discuss how to handle cleaning up records with missing emails.
Accounts data for a given term should be pulled with enough time enable access when needed. Campuses who are also importing Instructor and Enrollment files should align Accounts with the term logic used in these files so that any referenced accounts are created at the appropriate time.
Suggested SIS Tables
Accounts should be imported after Authentication is complete and BEFORE any other data is sent to Campus Labs.
When turning on automation in the middle of the term, students who have already completely withdrawn may not be included in the Accounts file, but they may be included in the Enrollments file with a “withdrawn” or “dropped” status. This discrepancy causes their enrollment records to error out, and you will need to manually load accounts for these users. The error report identifies these users. Once automation is running, this problem disappears because accounts are created as students enroll and drop.
Depending on what type of identifier you chose during authentication, you may encounter situations where a user’s identifier changes. One example is if you are using email as a PersonIdentifier, and the email includes the user’s name. If the user’s name changes for any reason and is updated in the SIS, the new email will NOT match with the existing PersonIdentifier in Campus Labs and a new, duplicate account will be created on import. Discuss how changes are entered into the SIS and establish a process for informing Campus Labs support of these changes BEFORE the file is imported so account mappings can be established between the two PersonIdentifiers.
|Baseline - Rubrics|
Requirements for populating this file can also be found in the Core Data Dictionary.