Clever, ClassLink and the sharing layer between you and the SIS

A district's roster lives in a student information system your product will never talk to directly. Something sits between you: a sharing layer the district controls, that decides how much you see, and that fails in ways your own monitoring won't catch.

Knowing the routes and their failure modes is most of what separates a smooth September from a bad one.

The source: student information systems

The SIS is the system of record for enrolment. PowerSchool SIS, Infinite Campus, Skyward, Aeries, Synergy, Tyler SIS, Focus, and a long tail of others. Between them they hold every fact about who attends which school and sits in which section.

Three things to understand, none of them technical:

It changes all day. A registrar enrols a student at 10:40 and the schedule changes at 11:15. Your copy is a lagging replica, and everyone involved knows that except, sometimes, your product.

It isn't yours to write to. Almost no integration writes back to the SIS. Grades go to a gradebook, which may or may not be the same vendor, and that's a different, narrower door.

Its data is entered by humans under time pressure, in August, at volume. This is where the ghost sections, the duplicate students and the teacher named "Do Not Assign" come from.

Route 1: Clever

Clever sits between thousands of districts and their applications, and for a large part of the US market it's the default answer to "how do we roster you".

• Secure Sync is the roster feed. Clever ingests from the district's SIS, normalises it, and exposes it to approved applications.
• Instant Login is the SSO half. A student clicks a tile in the Clever portal and lands in your product, authenticated.
• Clever Badges are QR sign-in cards for younger students without email addresses or reliable passwords. If you serve K-2, that isn't a nice extra. It's how those children get in at all.

Three things about Clever that shape your design:

The district controls sharing, at section granularity. This is the single most important operational fact in this post. A district administrator decides which schools, which sections and which fields you receive. You don't get to assume you have the district. You get what somebody ticked, and the ticks change.

Clever's id is your join key, not the SIS id. Clever exposes both. Use Clever's id as the external identifier for the Clever provider and store the SIS id alongside it, because the day a district switches to a direct OneRoster feed, that SIS id is your bridge.

Applications are reviewed, and administrators can see what you request. Ask for the minimum. A request for demographics you don't use is a question you'll answer during a privacy review.

Route 2: ClassLink

Similar ground, different centre of gravity, and particularly strong where a district wants to own its own plumbing.

LaunchPad is the portal. OneClick handles sign-in, including injecting credentials into legacy applications that never learned SSO. OneSync provisions accounts outward into Google Workspace and Entra ID, which is mostly relevant to you because it explains why a student's Google account exists at all, and why it sometimes appears a day after their SIS record does.

The piece that matters most: Roster Server turns the district's SIS into a conformant OneRoster provider you consume directly. So an integration described as "ClassLink" is often just a OneRoster integration whose endpoint happens to be hosted by ClassLink, and everything in OneRoster, honestly applies unchanged.

Route 3: A district-hosted OneRoster endpoint

Larger and more technically confident districts run their own OneRoster API, often from the SIS vendor's module. You get a base URL, a client id and a secret.

Cleanest route, most variable in quality. Conformance ranges from excellent to a partial implementation that returns 500 on demographics and paginates inconsistently.

Test the actual endpoint before you promise a timeline. Don't test the specification.

Route 4: Nightly CSV on SFTP

Unfashionable, extremely common, completely fine.

A zip lands at 02:00. You process it. The failure modes are operational rather than semantic:

• The file doesn't arrive.
• The file arrives truncated, because the export ran while the SIS was mid-transaction.
• The file arrives with a different column set, because someone updated the SIS.
• The file arrives identical to yesterday, because the export job failed silently.

Guard rails that pay for themselves: verify the manifest, alert on absence by a deadline rather than only on error, and refuse to process a payload whose row count dropped by more than a threshold without an explicit override.

That last guard is the one that matters most. A truncated export you apply faithfully looks exactly like a district that deleted two thousand students. You cannot tell them apart from the data, so don't try. Stop and ask a human.

Route 5: The LTI launch itself

An LTI 1.3 launch carries context with it, and Names and Role Provisioning Services lets you fetch the membership of that context on demand.

This is the freshest data available to you, because it's generated at the moment of the click rather than at 02:00. It's also the narrowest. You learn about a class when somebody from it launches, and never learn about a class nobody opened.

The useful pattern is both: a nightly sync for breadth, an NRPS call on launch for freshness, reconciled into the same tables. When a teacher says "I added a student this morning and they aren't here", the fix is a re-sync of that one class, triggered by the teacher. Details in SSO for schools.

The partial share is the default

Whichever route you use, plan for this exact sequence, because it's what happens.

1. A district shares 12 of its 40 schools while they evaluate you.
2. Everything must be correct on that subset. Reports, seat counts, admin views.
3. In November they share the other 28, without telling you.
4. Overnight your tenant triples. Any job with an implicit assumption about scale, any report cached at district level, any seat calculation, any "select all" in an admin interface now behaves differently.

Design for it. Never assume the roster you have is the roster that exists. Make scale-sensitive jobs adaptive rather than tuned. Treat a large delta as an event worth alerting on rather than a quiet Tuesday.

Choosing between them

If a district offers a choice, and larger ones will, this ranking has held up:

1. A district-hosted OneRoster REST endpoint, if it's conformant. Direct, fewest intermediaries, you own the relationship.
2. Clever or ClassLink, when the district already runs one. Don't fight this. If their administrators live in Clever, being outside it makes you harder to manage, and being harder to manage is a renewal risk.
3. CSV on SFTP, when nothing better exists. Boring and reliable.
4. LTI only, when your product is genuinely launch-scoped and you don't need to know about classes nobody opened.

Support more than one. Anyone serving more than a handful of districts runs all of these simultaneously, which is exactly why the identities table in the data model of a school isn't optional.