Sure, knowing the identity of a user is helpful, but edtech products also need to be able to distinguish a user’s learning institution, if they should receive product access, and the user’s role (to determine permission level). A product wouldn't want to give access to unlicensed users, direct users through the wrong U.I. flow, or give students access to keys reserved for teachers.

Data providers are how learning institutions manage all of their records like for teachers and students, which is why a rostering solution needs to connect to a data provider(s). In edtech, there are a few ways rostering solutions can get this information:

  1. A rostering solution can connect to a learning institution’s LMS
  2. A rostering solution can connect to a learning institution’s SIS
  3. A rostering solution can use a secure upload

LMS Integration

Many LMS providers allow for enrollment retrieval and other related data via their API. This method may require an administrator to connect their account to the edtech product, at which point the product may retrieve a list of enrollments from a user's courses in the LMS. There are two methods of LMS integrations: direct API integrations or by using the LTI specification. However, not every LMS supports the LTI specification.

SIS Integration

Just like LMS integrations, there are a couple of methods for building SIS integrations. An edtech developer can choose direct API integrations or use the OneRoster specification. However, again, not every SIS supports the OneRoster specification but some only allow it. Many rostering solutions base their data provider to come from a learning institution’s SIS.

OneRoster (SIS-Based)

OneRoster is a specification from 1EdTech that allows for the exchange of enrollment data between a product and a SIS. Once created, a OneRoster file can then be uploaded into a OneRoster-compliant product. OneRoster contains data such as names, email identifiers, course listings, and roles of users. Because of this specification, several rostering solutions use it.

ClassLink provides SSO and rostering solutions for educational products. ClassLink's services (like Roster Server) are built on the OneRoster standard. Roster Server is ClassLink's implementation of a OneRoster server. Learning institutions that work with ClassLink will install Roster Server as a virtual server on their network or in the cloud. An administrator will then either connect their SIS to Roster Server through the OneRoster API or upload CSV templates into the Roster Server that are formatted in the OneRoster specification.

When school administrators connect to an edtech product on ClassLink, the school's Roster Server will export their enrollments to the product through the OneRoster specification. Though it's not required, many products will use this data through another ClassLink product to provision accounts for users and enable single sign-on.

GG4L (OneRoster-Based)

GG4L offers rostering through its GG4L Connect solution. GG4L exposes its roster data through the OneRoster API.

Clever (SIS-Based)

Clever helps school administrators to connect their SIS to Clever. The students and teachers from a school can then log into Clever-connected apps with a single set of credentials. This entire process is free for schools. However, companies who want to be able to retrieve rostering data from Clever must pay for Clever's Secure Sync program.

Manual Upload | CSV-based

Many products allow learning institutions to upload roster information manually. This is certainly the most error-prone and time-consuming method to perform rostering. However, it may be necessary in the event that a learning institution or product does not support any of the previously mentioned methods for rostering. This process can either be performed by allowing teachers or administrators to create accounts for other users through an interface in the product, or by allowing the learning institution to upload rosters through a specified CSV format.

Outside of this list, there are two more points to talk about regarding rostering information.

  1. Ed-Fi
  2. A4L

Ed-Fi

Ed-Fi is a non-profit organization that promotes the use of its Ed-Fi data standard and the Ed-Fi API. Edtech vendors that work with districts that have adopted the Ed-Fi technology suite can use the Ed-Fi API to roster data into their products. Ed-Fi itself is not a product or rostering tool. It is a standard that other products can adhere to. There are a number of products on the market that implement the Ed-Fi specification, including Powerschool.

A4L

A4L is another non-profit that encourages the use and development of data standards for education, such as the SIF specification. A4L offers the xPress Roster API as a method to retrieve rostering data from schools that support SIF 3 data models.

Which rostering solution is right for you?

Edtech developers can go through the evaluation process with all of these solutions and will most likely realize they need more than one solution for rostering education data. In the past, some products choose to build their own solution or connect to one of these (or a combination of both). Edlink is a way to easily gain connections to these rostering solutions by building only 1 integration.

Update | 5.23.24


Learn More about Rostering

Here are other articles we’ve written about rostering and integrations to help you on your journey:

If you're looking for a partner who can help guide you through developing LMS integrations (like these), then let’s introduce ourselves. We’re Edlink!