Roster Management

Last Updated: Aug 22, 2016 12:06PM PDT
[Note: This article is meant primarily for technology staff that administer student information systems, as well as district and school leadership that coordinate implementations. This article will be updated frequently between now and approximately September 15th.]
[SIA: This article is in process of being edited for formatting/style.]

Introduction

On the early morning of August 22nd, 2016, the CCC Learning Hub will receive a major infrastructure update. Most users won't notice any change, but new import/export functionality, along with new file formats, for user and roster management will be available through the Customer Admin tool.

The intent of this change in process and format from the 2015-2016 school year is to allow customer admins (presumably with an IT background) to be able to perform roster management functions with little to no assistance from CCC Tech. It is also a precursor to a more automated "SIS integration" premium feature which will facilitate the one-way synchronization of relevant information from an institution's Student Information System (SIS) to the CCC Learning Hub.

Until further notice, only customer admins affiliated at the highest level of their institution will have access to this feature. In other words, if you are in a public school system, only customer admins affiliated with the district, rather than the school can access this tab.

Each user, student, and class has a required field for unique identification within the CCC Learning Hub platform. The intent is that these identifiers come from the institution's Student Information System (SIS). CCC refers to these fields as the SIS User ID, SIS Student ID, and SIS Class ID. While denoted as an SIS ID, these fields may have values that are generated in another way (other than an SIS) by the institution. For instance, when users create their own accounts, or when users do not to specify a SIS Student ID when creating a student, CCC assigns a random unique alphanumeric value for these fields.

The Customer Admin tool will have a method for SIS User, Student, and Class ID replacement to facilitate synchronization with the institution's SIS IDs. SIS ID replacement uploads may be done as many times as needed.

Data exchange format and logic

Attached to this support article are links to four CSV files:

  • USERS-SAMPLE.CSV
  • STUDENTS-SAMPLE.CSV
  • CLASSES-SAMPLE.CSV
  • ENROLLMENTS-SAMPLE.CSV

Each file is consistent with the format documented below and includes example entries.

All imports are done in “bulk”. In other words, when a customer admin does an import of one of the files below, the file must include the entire scope of elements. For instance, USERS needs to include all active users within the institution. Consequently, CCC recommends that the institution review an export of USERS and STUDENTS (users and students persist as static entities after a school year switchover) from the Customer Admin tool before uploading the corresponding imports.

Important Note: Export of USERS and STUDENTS will only include users and students with an active status. The customer admin tool will allow you to review, interactively, all users and students.

After an import of any given file, the system performs a validation of the relevant file, and returns a CSV validation file with the uploaded contents and an additional final entry for each row labelled “Result”, which specifies whether the entry is valid and any appropriate feedback. If there are any entries that are deemed invalid, the admin is informed and no changes are made to the associated data in the system. If the file passes validation, the import proceeds without any additional input from the admin.

Until further notice, each institution will only be allowed to upload one USERS, one STUDENTS, one CLASSES, and one ENROLLMENTS file for the 2016-2017 school year in the CCC Learning Hub. CCC strongly encourages institutions to test the process of import on our sandbox environment, which is distinct from the production environment available at ccclearninghub.org. Data on the sandbox environment can be reset to its initial, clean state upon request, allowing institutions to attempt the process multiple times on sandbox. For additional information about how to access the sandbox environment, please email support@collaborativeclassroom.org with subject line “Sandbox Request”.

While only one upload on production is currently permitted, customer admin users can interactively manipulate users, students, classes and their enrollments through the web application. Users can continue to manipulate students, classes, and enrollments within the scope of ClassView and the SIPPS Assessment app.

SIS ID replacement uploads can be done as many times as needed.


 

USERS.CSV

 

Fields:

 
  • SIS User ID: The SIS ID associated with the user.
    This is the primary “unique” ID for identification of the user within the system. If the institution doesn’t have an SIS system, CCC suggests that the institution implement a system to assign an ID that guarantees uniqueness of users within the entire institution (i.e., uniqueness across the institution at the highest level -- e.g., uniqueness across the entire public school district, not just uniqueness at a given school)

  • Email Address: The valid email address for the user.
    CCC strongly suggests that this email is the one provided by the institution (as opposed to a user’s personal email address). This email address is the primary key for identification during login. In addition, our organization will send critical notifications to this email address.

  • First Name

  • Last Name

  • Institution ID: A numeric field that CCC uses to identify each institution uniquely. (For public schools, there is a code for each school as well as the district itself.)
    The user will be affiliated with the institution selected. If a user is affiliated with multiple public schools, the public school district ID should be entered, as multiple affiliations are not yet supported. A list of the IDs for each institution relevant to the customer admin user is provided as a downloadable Excel file within the Customer Admin tool.

 

Validation Process:

 
  1. The file is not processed if the number of rows is more than 15,000.

  2. Ensure all fields have a valid, non-null value

  3. Ensure SIS User ID is unique (and doesn’t conflict with any inactivated users)

  4. Ensure the Institution ID is one associated with the institution with which the admin user is affiliated

 

Processing logic:

 
  1. If the user is “new” (the SIS User ID doesn’t already exist in the system), an email is sent to the user at the provided email address to inform them that their account is ready. There is a link in that email that will prompt the user to enter their desired password. After first login, each new user must go through an “onboarding” procedure to complete their profile. Until the user completes that profile, their status is "incomplete".

  2. If a previously defined SIS User ID is no longer present in the CSV file, the associated account will be marked inactive and deactivated. [In context of the future ability to perform multiple uploads during a school year, if that user was “joined” to any class via the ENROLLMENTS file, that relationship is broken. A normal workflow would include the subsequent upload of a new ENROLLMENTS file, in which a different user is associated with these disconnected class(es).]

  3. Changes to email, first/last name, and affiliation are processed. [In the context of the future ability to perform multiple uploads during a school year, if the affiliation is changed from one school to another school with a district, the relationship to any classes to which the user was “joined” via the ENROLLMENTS file is broken. If the affiliation is changed from a district to a specific school within the district, only the relationships to any classes (in the ENROLLMENTS file) associated with that specific school remain. A change in affiliation from a school in the district to the district itself will not alter any relationship to classes as defined in the ENROLLMENTS file.]

 

Notes:

 
  1. While it is possible to inactivate (or reactivate) a user, it is not possible to delete a user or any of the data they've created in system.

  2. A user’s roles (e.g., SIPPS Admin, Customer Admin) are not within the scope of the import/export.

  3. A user’s program selections and entitlements are not within the scope of the import/export.

 

STUDENTS.CSV

 

Fields:

 
  • SIS Student ID: The SIS ID associated with the student.
    This is the primary “unique” ID for identification of the user within the system. If the institution doesn’t have an SIS system, CCC suggests that the institution implement a system to assign an ID that guarantees uniqueness of students within the entire institution (i.e., uniqueness across the institution at the highest level -- e.g., uniqueness across the entire public school district, not just uniqueness at a given school).

  • First Name

  • Last Name

  • School ID: The numeric field that CCC uses to identify each school.
    The student will be affiliated with the school selected. Unlike users, students must be affiliated with a school -- they can’t be affiliated at the district level. A list of the IDs for each school (and the district) is provided as a downloadable CSV file within the Customer Admin tool.

  • Student’s Current Grade: The numeric field designating the student’s grade for the current school year.

 

Allowed values are:

 

Value

Grade

-2

P3

-1

P4

0

K

1

1

2

2

3

3

4

4

5

5

6

6

 

Note: Use P4 for students in PK, TK

 

Validation Process:

 
  1. The file is not processed if the number of rows is more than 30,000.

  2. Ensure all fields have a valid, non-null value

  3. Ensure SIS Student ID is unique (and doesn’t conflict with any inactivated students)

  4. Ensure the School ID is one associated with the institution of the admin user

  5. Ensure the Student’s Current Grade is an integer between -2 and 6

 

Processing logic:

 
  1. If a previously defined SIS Student ID is no longer present in the CSV file, the associated student will be marked inactive (no longer attending the institution -- for public schools, this means the student is no longer attending any school in the district). [In the context of the future ability to perform multiple uploads during a school year, If that student was “joined” to any class via the ENROLLMENTS file, that relationship is broken.]

  2. Changes to first/last name, affiliation, and grade are processed. [[In the context of the future ability to perform multiple uploads during a school year, if the affiliation is changed from one school to another school, the relationship to any classes to which the student was “joined” via the ENROLLMENTS file is broken. Changes to the student’s grade will, on their own, not invalidate the associated entry in the ENROLLMENTS file.]

 

Notes:

  1. While it is possible to inactivate (or reactivate) a student, it is not possible to delete a student or any of the data associated with the student in the system -- that data is simply "hidden".

 

CLASSES.CSV

 

Fields:

 
  • SIS Class ID: The SIS ID associated with the class.
    This is the primary “unique” ID for identification of the class within the system. If the institution doesn’t have an SIS system or has one that doesn’t generate class IDs, CCC suggests that the institution implement a system to assign an ID that guarantees uniqueness of classes within the entire institution (i.e., uniqueness across the institution at the highest level -- e.g., uniqueness across the entire public school district, not just uniqueness at a given school). A typical designation will include the physical location of the classroom.

  • Class Name: The name of the class as it appears to the user on the CCC Learning Hub (e.g., ClassView)

  • School ID: The numeric field that CCC uses to identify each school.
    The class will be affiliated with the school selected. Classes must be affiliated with a school -- they can’t be affiliated at the district level. A list of the IDs for each school (and the district) is provided as a downloadable CSV file within the Customer Admin tool.

 

Validation Process:

 
  1. The file is not processed if the number of rows is more than 2,000.

  2. Ensure all fields (except Class Name) have a valid, non-null value

  3. Ensure SIS Class ID is unique (within the scope of the current school year)

  4. Ensure the School ID is one associated with the institution with which the admin user is affiliated

  5. In the context of the future ability to perform multiple uploads during a school year, if the SIS Class ID already exists and the SIS School ID changes, a validation error will occur. A new SIS Class ID should be generated if a class somehow moves from one school to another.]

 

Processing logic:

 
  1. When uploading this file, the customer admin will have the option to select one of three options IF the institution (currently, restricted to specific public school districts) is part of the field test for the SIPPS coordinated model:

    1. ClassView

    2. SIPPS

    3. ClassView + SIPPS

  2. The Class Name will be set to the SIS Class ID value if the field is left blank. (The user will be able to modify the ClassView Class Name within ClassView. The Class Name has no relevance in SIPPS.)

  3. In the context of the future ability to perform multiple uploads during a school year, if the class already exists and the Class Name is blank, the Class Name will not be altered.

  4. In the context of the future ability to perform multiple uploads during a school year, if a previously defined SIS class ID is no longer present in the CSV file, the associated class will be marked inactive. Any users or students “joined” to that class via the ENROLLMENTS file will no longer be connected.

 

Notes:

 
  1. While classes are defined in the context of school year, the associated SIS Class ID values must be unique for each school year. While it may be useful for human readability to maintain distinct SIS Class ID values for each school year, the system will allow the same SIS Class ID from one school year to the next.

  2. While it is possible to inactivate (or reactivate) a class, it is not possible to delete a class or any of the data (e.g., ClassView group assessments) associated with the class in the system. (That data is simply "hidden".)

  3. SIPPS groups and Small Groups in Being a Reader are not within the scope of this file.

  4. If the institution (currently, only a selected number of public school districts) uses the SIPPS coordinated model, SIPPS homerooms are within the scope of this file. SIPPS classrooms are determined by the SIPPS Admin and are not within the scope of this file.

  5. If the institution uses the SIPPS independent model, users (teachers) will add students by SIS ID -- either as they perform a placement exam (new students to SIPPS only) or as they add prior year students to their unassigned drawer for grouping.

  6. Definition of the scope of the ClassView class (the program grade, and which of the Collaborative Literacy programs -- Being a Writer, Making Meaning, or Being a Reader -- are included) is performed within ClassView by the user (teacher) designated in the ENROLLMENTS file.

  7. While not important for end users, be aware that the CCC data model has a structure in which the SIS Class (as defined via this import) serves as a “parent” to an associated ClassView Class and/or SIPPS Homeroom Class (in the SIPPS coordinated model). [In the context of the future ability to perform multiple uploads during a school year, depending on user and admin actions and the order in which they occur, it is possible to orphan a ClassView class and not be able to retrieve it without CCC assistance.]

 

ENROLLMENTS.CSV

 

This is the file that defines the relationships between users, students, and classes. Hence, it will have about as many rows as the USERS and STUDENTS put together.

 

Fields:

 
  • SIS Class ID: The SIS ID associated with the class of interest.

  • SIS Member ID Type: A numeric designation as to whether the following entry is a user (1) or student (2).   

  • SIS Member ID: The SIS ID associated with the member (user or student) that should be connected to the aforementioned class.

 

Validation Process:

 
  1. The file is not processed if the number of rows is more than 50,000.

  2. Ensure both SIS ID fields have a valid (defined and “active”) ID

  3. Ensure that both elements are affiliated at the same school (i.e., users affiliated at a public school district can be joined to any class at any school within their district)

  4. Ensure that both elements (class, and user or student) are both “active”.

  5. Ensure that only one user (teacher) (and at least one) is connected to each class

  6. An error is recorded in the response file if there are more than 50 students in a class.

 

Processing logic:

 
  1. In the context of the future ability to perform multiple uploads during a school year, if a previous enrollment (connection of a user or student with a class) is no longer listed, the connection is removed.

  2. All connections listed are made.

 

Notes:

 
  1. Teachers can have multiple classes. Students can be in multiple classes.

  2. While classes must have one (and only one) user (teacher), classes can have no students (even though that is of limited value).

support@collaborativeclassroom.org
http://assets1.desk.com/
false
desk
Loading
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
about
false
Invalid characters found
/customer/en/portal/articles/autocomplete