Buzz supports the rostering of users, courses, enrollments, and observers, and grade passback through the 1EdTech (formerly IMS) OneRoster specification. The SIS Sync makes rostering and grade passback easy and automated.
How do I sync with Student Information Systems (SIS) in Buzz?
What is OneRoster?
OneRoster is a 1EdTech specification for exchanging data between systems. Commonly, this exchange will happen between the student information system (SIS) and the learning management system (LMS). For these FAQs, Buzz is the LMS.
What version of OneRoster does the SIS Sync support?
The SIS Sync supports OneRoster 1.1.
What data exchange modes does the SIS Sync support for rostering?
The SIS Sync supports the CSV and REST API modes for rostering.
What data exchange modes does the SIS Sync support for grade passback?
The SIS Sync supports the REST API mode for grade passback.
What is the CSV mode for rostering?
The CSV mode is a collection of CSV files (packaged together as a OneRoster zip file). Once uploaded to the SIS Sync, the CSV files are processed to create, update, and/or delete data from Buzz.
What CSV files are required in the SIS Sync?
- manifest.csv
- academicSessions.csv
- classes.csv
- courses.csv
- enrollments.csv
- orgs.csv
- users.csv
What header fields are required in the CSV files for rostering?
According to the OneRoster specification, every header field is required to be included in the CSV file. In addition, the header fields must be provided in the correct order and are case sensitive. Refer to CSV Format for more details.
Do all of the CSV rows for rostering need to contain values for each header field?
No. However, you are expected to provide a value for each header field that is required according to the OneRoster specification. Refer to CSV Format for more details.
For example, in the academicSessions.csv you are required to include the header field (i.e., column) parentSourcedId, but you are not required to provide a value in the corresponding rows.
Example (displayed as a table for readability):
| sourcedId | title | type | startDate | endDate | parentSourcedId | schoolYear |
|---|---|---|---|---|---|---|
| 123456 | Fall | term | 2020-09-01 | 2020-12-18 | 2021 | |
| 234567 | Winter | term | 2021-01-04 | 2021-03-26 | 2021 | |
| 345678 | Spring | term | 2021-03-29 | 2020-06-25 | 2021 |
How are the property values mapped between the OneRoster zip file for rostering and Buzz?
| File | Property Name | Mapping |
|---|---|---|
| academicSessions.csv | title | Course term |
| startDate | Course start date | |
| endDate | Course end date | |
| schoolYear | Base course title, Course term | |
| classes.csv | sourcedId | Course external ID |
| title | Course title | |
| grades | Course metadata | |
| courseSourcedId | Base course | |
| classCode | Course metadata | |
| classType | Course metadata | |
| location | Course metadata | |
| schoolSourcedId | Course domain | |
| termSourceId | First term listed is used to determine the course term, start date, and end date | |
| subjects | Course metadata | |
| subjectCodes | Course metadata | |
| periods | Course metadata | |
| courses.csv | title | Base course title |
| courseCode | Base course external ID Base course title |
|
| enrollments.csv | sourcedId | Enrollment external ID |
| classSourcedId | Enrollment course | |
| schoolSourcedId | Enrollment domain | |
| userSourcedId | Enrollment user | |
| role | Enrollment role | |
| primary | Enrollment metadata The primary teacher is the one used to create teacher and term masters |
|
| orgs.csv | sourcedId | Domain external ID; only on domain creation |
| name | Domain name; only on domain creation | |
| type | Domain metadata | |
| identifier | Domain metadata | |
| parentSourcedId | Domain parent; only on domain creation | |
| users.csv | sourcedId | User external ID |
| enabledUser | User metadata | |
| orgSourcedIds | First org listed is used to determine the user domain | |
| role | User metadata Observer accounts |
|
| username | User username | |
| userIds | User metadata | |
| givenName | User first name | |
| familyName | User last name | |
| middleName | User metadata | |
| identifier | User metadata | |
| User email | ||
| sms | User metadata | |
| phone | User metadata | |
| agentSourcedIds | Observer accounts | |
| grades | User metadata | |
| password | User password; only on user creation NOTE: If no password is provided for a new account, then the user’s password will have to be reset or the user will only be able to login through SSO. |
How can I learn more about these CSV files for rostering?
Visit the 1EdTech (formerly IMS) OneRoster: CSV Tables website.
Is there an example OneRoster zip file with the supported CSV files?
Yes, you can find an example OneRoster.zip file here. This zip file only includes the supported CSV files.
Does my SIS natively support exporting OneRoster CSV or zip files for rostering?
You can review the tools that have been certified to support OneRoster Rostering CSV Export Bulk. However, many other SIS support this functionality even though they are not certified. Reach out to your SIS administrator to learn if your SIS can export OneRoster files.
What privileges does the administrator need to use the SIS Sync?
To use the SIS Sync, the Buzz administrator must have each of the following domain privileges.
- Domain
- Owner
- Create
- Read
- Edit
- Delete
- Report
- Users
- Owner
- Create
- Read
- Edit
- Delete
- Report
- Courses
- Read
- Owner
- Create
- Read full
- Delete
- Edit
- Delete
- Report
- View gradebook
- Setup gradebook
- Grade assessments
- Grade assignments
- Grade discussions
- Submit final grades
- Enrollments
- Owner
- Read
What actions does the SIS Sync rostering integration perform?
The SIS Sync may create, update, and delete various entities shared with Buzz. Specifically, these entities include:
- Users: Students, teachers, school and district admins
- Courses: District, school, and teacher master courses; section courses
- Enrollments: Student and teacher enrollments
- Domains: Schools, districts, states, departments, etc.
- Observers: Parents, guardians, and relatives
What data will be created in Buzz?
The SIS Sync may create the user, courses, enrollments, domains, and observer associations for the data shared with Buzz.
What is a base course?
Buzz allows for multiple derivative courses to be managed (e.g., settings, content) from a base course. The derivative course receives updates from the base course as long as it was not explicitly changed in the derivative course. This workflow allows for efficient curriculum development and distribution while still allowing for teachers and schools to further enhance their course.
The SIS Sync may create organization (e.g., state, district, school) base courses, a teacher base course, and academic session base course for every course that is taught. The classes (i.e., where student enrollments exist) will be created as derivative courses of the academic session base course, or the next available base course. This means that settings or content added to the state base course will be inherited by all organization base courses and subsequently the teacher/academic session base courses and the section courses.
In the example below, there is:
- A state organization
- Two school district organizations
- Three school organizations
- Three teachers
- Two academic sessions per teacher
- A total of ten section courses (or “classes”)
The higher in the hierarchy content or changes are made, the more derivative courses that would receive the change. For example, if a new assessment were to be added to the:
- State organization base course, this assessment would appear in each distinct organization base course, school organization base course, teacher base course, academic session base course, and course section.
- School base course, it would appear in each teacher base course, academic session base course, and section course.
- Teacher base course, it would appear in each of that teacher’s academic session base courses section courses.
If the settings or content is supposed to be available to all students in the:
- state, then it should be added to the state organization base course.
- district, then it should be added to the district organization base course.
- school, then it should be added to the school organization base course.
- teacher’s courses for the current and future sections, then it should be added to the teacher base course.
- teacher’s courses for a specific academic session, then it should be added to the teacher’s academic session base course.
- specific section course, then it should be added to the section course.
How are base courses created?
A base course will be created for each unique courseCode found in the courses.csv. In the case where a courseCode does not exist, a base course will be created for each sourcedId in the courses.csv.
By using the courseCode to create base courses, it allows for courses at different organizations to use a different sourcedId while sharing the same courseCode.
Who is enrolled into the different types of courses?
- Organization base course: Nobody. Buzz Administrators should manually enroll curriculum developers and other users, as necessary.
- Teacher base course: The primary teacher of the particular course. Each teacher may get their own teacher base course for each unique course they teach.
- Academic Session Base Course: The primary teacher of the particular course. Each teacher may get one or more Academic Session base course for each unique course they teach, and for each term that course is taught in.
- Section course: The teacher(s) and students of the section course.
Will Buzz Administrator accounts be created automatically?
No, the SIS Sync will not create Buzz Administrator accounts automatically.
Can I change information created by the SIS Sync?
No. When you change some information that is managed by the integration, it will likely be reverted the next time the sync runs. For example, if you manually change a user’s first name in Buzz from “Bradley” to “Brad,” it will revert back to “Bradley” the next time the sync runs if the user’s first name is Bradley according to the SIS.
Any changes should be managed in the organization’s SIS. Changes to these fields will automatically be reflected in Buzz upon the next sync.
How can I tell if the user, course, or enrollment is managed by the SIS Sync?
If the user, course, enrollment, or domain has an external ID that is prefixed with “or-”, then it will be managed by the SIS Sync. Buzz Administrators can review if the entity has an external ID by looking at the list of users, courses, enrollments, or domains in the Admin app.
Can I have users, courses, enrollments, and domains that are not managed by the SIS Sync?
Yes. Administrators can create users, courses, and enrollments that are not managed by the SIS Sync. If these are created, do not provide an external ID for the entity that has a prefix of “or-”. If you create one with an external ID that begins with “or-”, it will become managed by the SIS Sync. If the user, course, or enrollment is not found in subsequently provided syncs, it may be deleted.
However, if you manually create an entity and a comparable entity is also in the sync, there is a likelihood that you will have a duplicate entity. For example, a user created manually and one created by the SIS Sync.
How often is the SIS Sync run?
The SIS Sync is run soon after a OneRoster zip file is sent to Buzz or the API sync is triggered. It can be run as frequently as the organization desires. In general, we recommend not sending a OneRoster zip file to Buzz more frequently than every 12 hours. To schedule an API sync, contact Agilix Support.
Where in Buzz are users created?
Users are created in the domain that is associated with the first organization for the user.
Where in Buzz are the courses created?
Organization base courses are created in the domain that is associated with the organization. Teacher base courses, academic session bases courses, and section courses are created in the domain associated with section courses.
If a teacher or admin creates a course outside of the SIS Sync, will it be changed by the sync?
As long as the course external ID does not prefix with “or-”, it will not be modified by the SIS Sync.
If a user, course, or enrollment is deleted from the SIS or no longer shared with Buzz via the SIS Sync, how will it impact Buzz?
If deleted from the SIS or no longer shared, by default, it will not be deleted from Buzz.
However, if the configuration option is set to delete any of these, then they will be deleted. If the exact same user or course is then reshared, Buzz will attempt to restore the user or course previously used. If the exact same enrollment is later reshared, Buzz will create a new enrollment.
How can I use an existing Buzz course as an SIS Sync-managed course?
There are times that you want to use an already existing Buzz course as a SIS Sync-managed course. For example, you created a course that you want to be used as a school organization base course. To do so:
- Identify the SIS Sync-managed school organization base course in Buzz.
- Update the manually created course to have the same external ID as the managed school organization master course.
- Delete the external ID from the undesired school organization base course.
The next time the sync runs, it will update all teacher base courses to point to the new school organization base course. Follow the same process for replacing any of the SIS Sync-managed courses with a manually created course.
What determines if base courses are created for a section course?
For a section course to have a base course, the section course must have a course code with the associated course in the SIS Sync.
What will happen to users, courses, and enrollments that exist in Buzz before the SIS Sync?
Any user, course, enrollment, or domain that does not have a matching external ID will not be managed by the SIS Sync.
What will happen to a user that is moved from one school to another in the SIS Sync?
If a user is moved from one school to another, whether due to a transfer or advancement, the SIS Sync will move the user to the new school along with all of their past information. This will occur if the following conditions are met.
- The user’s
sourcedIddid not change in the SIS Sync. - The two school organizations exist in the same SIS Sync.