Clever Library - Rostering

Overview

Rostering through Clever Library is a great way to get a taste of the power of Clever without the cost of Secure Sync.

If the teacher consents, your application will be authorized to access the following limited set of data fields for class information only belonging to that teacher. You'll use this data to automatically create user accounts and set up classes to make the signup experience as smooth and seamless as possible. Once a teacher authorizes this connection, your application will have access to all their sections, regardless of when they're created.

Teacher object data

• Clever ID - globally unique and stable ID for each user, created by Clever
• Name (first, middle, last)
• Email

Teacher’s shared sections, as primary or co-teacher

• Clever ID
• Name
• Section_number
• Teachers
• Students
• Subject (normalized to a set of possible values)*
• Grade (if available from the SIS)*

Student object data in those sections

• Clever ID (this is not sid_id or student_number; it’s a GUID generated by Clever)
• Name (first name, last initial)
• Grade (if available from the SIS)*

📘

Normalized Fields

Clever normalizes certain fields to a defined set of possible values:

Subject: ["english/language arts","math","science","social studies","language","homeroom/advisory", "interventions/online learning","technology and engineering","PE and health","arts and music","other",""]

Grade: ["1", … ,"13", "PreKindergarten", "TransitionalKindergarten", "Kindergarten", "InfantToddler", "Preschool", "PostGraduate", "Ungraded", "Other", ""]

For more details on each field, and to see how the Library “teacher-shared” set of data fields compares with full rostering “district-shared” fields, please refer to Clever's Data Schema.

🚧

Why are school info, district info, and full student name not provided for Library users?

We don't share district ID, school ID, and full student name in order to limit the data shared to what most districts consider a "non-PII" signup for students.

This has been instrumental in getting districts excited about the Clever Library and promoting it to their teachers as a good way to sign up for new applications. About half of our current integrated apps do require school and/or district information, and in those cases, build in as part of the onboarding flow when a teacher first logs in this way a prompt for the teacher to pick their school.

Best Practices

We've provided some best practices for managing the rostering portion of your Library integration below.

Account Matching

Oftentimes, users will already have an existing account with your application. It'd be best to provide some sort of account matching functionality upon sign-up or somewhere within the UI. Here are some ways you can approach this:

• Detect an existing email address. If the teacher's Clever-provided email address matches one you already have stored, prompt the user to confirm the match. You can have them provide the credentials to their existing account as an authentication step.
• Provide a tool that allows the user to manually link their existing account. In this case, you can also ask the user to provide the credentials to their existing account as an authentication step.

Once the user has confirmed their desire to match, you can link the user's Clever ID to their original account.

User Onboarding

With the Library integration, the user should be able to skip most of the registration flow. However, if you have required information that is not included with the Library integration (i.e. district information, school information, demographic/personal information), you are advised to include prompts for this information during user onboarding.

How to Sync Sections and Students

One of the biggest selling points of the Library integration is your ability to pull in section and student data. There are a few common approaches for how you choose to sync this information into your application:

• Automatically sync all sections and students
  • You might choose to just roster all sections and students associated with a teacher. While this is an easy option, some teachers may not want to bring all of their rosters into their application. This option give less flexibility to the teacher, though it might be easier to implement.
• Provide a "Sync Classes" tool
  • You can provide the teacher with a tool that allows them to select which sections and rosters they want to bring in. This gives the teacher more control over what data they're sharing and allows them to stay organized.

Plan for Transitioning to Secure Sync

Oftentimes, applications that choose to build a Library integration go on to build a district-level Secure Sync integration as well. It's advisable to prepare for this eventual transition. You may want to implement some of the following:

• Include logic to differentiate between "authorized_by" = "teacher" and "authorized_by" = "district" responses at the /me endpoint.
• Design your data schema to easily add in additional fields that are available with Secure Sync.