Clever vs ClassLink: how do districts choose, and what do they actually do?

What a rostering broker actually does

Strip away the branding and both platforms perform three jobs. First, they extract roster data from your SIS — students, staff, schools, sections, enrollments, and often demographics — on a recurring schedule, usually nightly. Second, they hand that data to each application you have authorized, in whatever shape that application accepts, so the vendor does not have to build a connector for every SIS in the country. Third, they act as an identity provider so students and teachers sign in once and land in a portal of application tiles.

The value is almost entirely in the second job, and it is worth being clear-eyed about why. The hard part of rostering has never been the technology; it is that several thousand districts and several thousand applications would otherwise need connections between them, each with its own field mappings, its own idea of what a section is, and its own onboarding call in August. A broker collapses that to one connection per district and one per vendor. That is a real and substantial service.

The third job, single sign-on, is a standard capability — SAML and OIDC are open protocols that many systems implement, including Google Workspace and Microsoft Entra ID, which most districts already run. What the brokers add on top is the portal experience and the fact that thousands of applications already have a configured integration waiting, which is convenience rather than capability.

The cost of the model is coupling. Applications integrated through a broker are configured against that broker specifically — its hostnames, its credentials, its identifiers — so the connection is not portable between providers or to a district-run identity provider without reconfiguring each application with its vendor. Anyone telling you a switch is invisible to your applications is describing something other than how these integrations work.

The business model difference, and why it matters

This is the most consequential practical difference. Clever's rostering platform is provided to districts at no charge; its revenue comes from the application providers that integrate with it. ClassLink is licensed by the district, typically priced per user with the total depending on district size and which components you buy.

The obvious reading is that one is free and one is not, and the obvious reading is incomplete. A district paying for a platform is the customer of that platform, and gets the attention and the roadmap influence that implies; a district using a platform funded by application providers is a participant in a network whose commercial relationships are with the applications. Neither arrangement is wrong, and both are common in education technology, but they produce different behavior over time and it is worth understanding which one you are in.

The budget question is also less clean than it looks. Free at the district level means the cost is embedded in what your application vendors charge you, since integration fees are a cost of doing business that gets priced into products. The paid model makes the line item visible. Whether visible or embedded cost is preferable is genuinely a matter of district finance philosophy.

For evaluation purposes, get an actual quote rather than reasoning from published rates, and get it for the components you would really deploy — a portal-plus-rostering-plus-analytics bundle is a different number from rostering alone. And on the other side, confirm which of the applications you use are already integrated, because that is the value you are getting and it varies by district's application mix more than by anything else.

Where the products actually differ in practice

Both provide a student and teacher portal of application tiles with single sign-on. ClassLink's LaunchPad has historically been the more configurable of the two, with a large library of single sign-on connectors and the ability to surface file storage from Google Drive, Microsoft 365, and other cloud storage alongside application tiles. Districts that want the portal to be the student's actual home page tend to like this. Clever's portal is deliberately simpler, and districts that use Google Workspace as the student's front door often care less about portal depth.

Analytics is a real differentiator and is where ClassLink invests visibly. Its analytics products report which applications are being used, how often, and by whom, aggregated up to the district level, and the extended tier covers usage of digital resources broadly to inform purchasing decisions. If proving or disproving the value of your software spend is a live question for your district — and after the federal relief funding cycle it is a live question for most — that capability has direct budget consequences.

On data sources and standards, ClassLink's Roster Server is certified against the 1EdTech OneRoster standard and supports OneRoster API and CSV delivery alongside direct SIS connections and file-based imports, which matters if you have applications that consume a standard feed rather than a proprietary one. Clever also supports standards-based delivery, and both maintain direct integrations with the major SIS platforms. The practical question is narrower than the marketing: does the specific SIS you run, at the specific version you run, sync cleanly, and can the platform express the parts of your data model that are unusual — multi-school enrollments, co-teachers, alternative programs, mid-year section changes.

Directory and account provisioning is worth checking separately. Districts that need accounts created and disabled in Active Directory, Entra ID, or Google Workspace from roster data should evaluate that capability specifically, since the depth differs and it is often the piece that saves the most staff time.

How to actually run the evaluation

Start from your application list, not from a feature matrix. Write down every application that needs roster data or single sign-on, mark which ones your teachers would revolt over losing, and ask each platform which of those are already integrated and at what depth — full rostering, single sign-on only, or manual file exchange. That list will differentiate the two platforms for your district more than any published capability comparison, and the answer is genuinely different from district to district.

Ask pointed questions about the applications that are not integrated. What is the path? Who does the work? What does it cost, and how long does it take? Every district has at least a few local or regional applications that will never be in anyone's library, and how gracefully a platform handles a custom OneRoster feed or a CSV drop is the difference between a workable deployment and a permanent manual process.

Test the SIS sync against your real data before committing, including the messy parts. Every district has records that break assumptions — students enrolled at two schools, sections team-taught, a preschool program the SIS models differently, staff who are also parents. Ask for a pilot sync with actual data and look at what came through, rather than accepting a demonstration on clean sample records.

Establish who does the work at renewal and in August. Rostering is not set-and-forget; a new school year changes every section, every enrollment, and half the staff assignments. Ask what the August process looks like, who at the vendor supports it, and what the escalation path is when an application receives bad data on the first day of school. The answer to that question predicts your year more accurately than the feature list does.

Finally, ask both platforms plainly what leaving looks like: what data you can export, in what format, and what your applications would need to do. It is a fair question, the answer is instructive, and a vendor's comfort with it tells you something.

And consider the case for neither. If your application list is short, or your applications support OneRoster directly, or you already run Google Workspace or Entra ID as a full identity provider, a district-run integration may cover the requirement without a broker. That is a smaller set of districts than it sounds like — the broker's value is real when your application list is long — but it is not an empty set, and it is worth ruling in or out before you sign.

Common misconceptions worth clearing up

The first is that a broker replaces your student information system. It does not; it reads from it. The SIS remains the system of record for enrollment, and the quality of what comes out of the broker is bounded by the quality of what is in the SIS. Districts that adopt rostering and discover their downstream data is wrong have usually discovered that their SIS data was wrong all along, and no broker fixes that.

The second is that single sign-on and rostering are the same thing. They are separate: rostering moves class lists so an application knows a student belongs in a section, and single sign-on lets that student authenticate without a password. An application can be rostered without single sign-on, or offer single sign-on without receiving rosters, and mixing the two up leads to buying a capability you already have.

The third is that switching providers is a district-side project. Because each application is configured against a specific provider's endpoints and credentials, changing brokers means each vendor reconfigures their side. It is a coordinated effort across your entire application list, best done at a year boundary, and the districts that have done it will tell you the schedule was set by their slowest vendor.

The fourth is that either platform relieves you of data governance. You are still the party responsible for deciding which applications receive student data and which fields they get, and both platforms give you controls to make those decisions. That authorization decision is yours, it belongs in a documented process with your privacy officer, and it does not transfer to the platform because the platform has a relationship with the application.