The step most rollouts get wrong is not technical. It is that the choice of which integration services to enable determines what personal data leaves your institution — and it is usually made by an engineer in a configuration screen rather than by the people who signed the data protection assessment. Get that decision into the right hands and the rest of this is a fortnight of ordinary work.
What follows is the sequence, with the owner and the artefact for each step, in the order a university actually has to do them.
Step 1 — Decide the identity model before you touch anything
Owner: identity and access management lead, with the platform’s academic owner. Artefact: a one-page decision record.
Two models, and they are not interchangeable:
- Identity-provider entitlement. Users sign in through the institutional IdP and entitlement is carried in the identity assertion. Access follows the person, works outside any course, and is deprovisioned by the joiner-mover-leaver process you already run.
- LMS-launch entitlement. Users reach the platform from inside a course. Access follows enrolment, is scoped to the course context, and disappears when the course does.
The choice decides three downstream things: how you count licences, how deprovisioning works, and where a confused user goes for help. Institutions that defer it end up doing both, which doubles the support surface and produces two populations with different entitlements and no way to reconcile them.
Step 2 — Agree the attribute release, attribute by attribute
Owner: IAM lead with the data protection officer. Artefact: a signed attribute release list.
This is the data-minimisation decision inside SSO, and it is the one the DPO must own rather than review. For each attribute the vendor requests — persistent identifier, name, email, affiliation, entitlement, department — record what it is used for and whether the service degrades without it.
Two rules that save arguments later:
- Prefer a pairwise, non-reassignable identifier over anything that doubles as a human-readable institutional identifier. It supports account continuity without exporting your internal identity scheme.
- Treat “nice to have” as “no”. Attributes are trivially added later and painfully removed, because by then something depends on them.
Where SAML federation is in use, this list is the metadata you publish; where OpenID Connect is used, it is the scope and claims set. The protocol matters less than the discipline.
Step 3 — Select the LTI Advantage services deliberately
Owner: LMS administrator with the DPO. Artefact: a service-by-service justification, filed with the DPIA.
1EdTech’s Learning Tools Interoperability specification “allows learning management systems (LMS) or platforms to integrate remote tools and content in a standard way”, and the current version, LTI 1.3, “builds on previous versions by improving the authentication security model” — introducing the 1EdTech Security Framework “based on OAuth2 and JSON Web Tokens”.
On top of that security model sit the LTI Advantage services, and each one moves different data:
| Service | What it does (per 1EdTech) | What that means for your DPIA |
|---|---|---|
| Names and Role Provisioning Services 2.0 (NRPS) | “provides access to data about users and their roles within organizations; a school, platform (LMS), or course are examples of an organization” | The tool can enumerate your course membership and roles. This is a disclosure, not a convenience |
| Assignment and Grade Services (AGS) | “provides a way to create a gradebook column and post grades associated with a resource link” | The tool writes into the system of record for assessment. Scope, audit and rollback need answers |
| Deep Linking 2.0 (DL) | lets a platform user “launch a URI specified by the digital curriculum supplier (external tool), select specific content, and then receive a URI that other users can use to launch directly to that content” | Lowest data impact of the three; usually the right place to start |
The practical rule: enable Deep Linking first, add AGS only if grades genuinely need to flow back, and treat NRPS as a decision requiring a written justification. A pilot rarely needs membership enumeration at all, and starting without it gives you a clean baseline to add from.
1EdTech also publishes adjacent standards you may be asked about in the same meeting — OneRoster for roster exchange between teaching and learning systems, Edu-API for administrative system integration, Caliper Analytics for activity data, and the TrustEd Apps programme for supplier vetting. Knowing which of these your integration does not use is as useful in a committee as knowing which it does.
Step 4 — Run the security and privacy reviews in parallel, not in series
Owner: information security with the DPO. Artefact: a completed assessment and a risk register entry.
These two reviews ask different questions of the same vendor and are routinely run one after the other, adding six weeks for no benefit. Send both question sets at once. The data protection sequence, with the artefacts each step produces, is in our guide to running a data protection review before deploying an AI writing tool, and the written vendor question set is in our procurement question bank.
One question belongs to this step specifically and is easy to forget: what does the integration log, where do those logs live, and for how long. Launch logs contain identifiers and course context, and they are frequently outside the scope of the main processing description.
Step 5 — Build in a non-production tenant with representative data
Owner: LMS administrator. Artefact: a configuration runbook.
Sandbox testing with three tidy courses proves nothing. The cases that break integrations are the ones your institution already has: cross-listed modules, students enrolled in multiple roles, teaching assistants with partial permissions, and courses with more than a thousand participants. Test those four deliberately.
Write the runbook as you go rather than afterwards. It becomes the change record, the handover document and the rollback plan, and writing it later means writing it wrong.
Step 6 — Schedule against the academic calendar, not the project plan
Owner: change advisory board. Artefact: a dated change request.
The windows that work are between terms and in the first two weeks of a term. The windows that do not are anything touching an assessment period. This is not risk aversion: an authentication change during a submission week converts a minor defect into an academic appeal, and the appeal outlasts the fix by months.
Book the rollback window at the same time as the change window. A rollback plan with no scheduled slot is an intention.
Step 7 — Prove deprovisioning before go-live
Owner: IAM lead. Artefact: a tested leaver scenario.
Provisioning is tested by everybody because it fails loudly. Deprovisioning fails silently and is therefore tested by almost nobody. Run one real leaver end to end and record: when access stops, what happens to their content, whether the licence seat is released, and what a returning student sees.
That last case is common in graduate education, where interruption and resumption are normal, and it is where seat-counting disputes with vendors originate.
Step 8 — Publish the support path before you announce the tool
Owner: service desk manager. Artefact: a triage script.
Three failure classes will arrive in your first fortnight: cannot sign in, signed in but sees nothing, and signed in as the wrong role. Each has a different owner — IdP, LTI configuration, and role mapping respectively. A triage script naming which team takes which symptom prevents every ticket landing with the LMS team by default.
A realistic timeline
| Phase | Elapsed | Gate |
|---|---|---|
| Identity model and attribute release agreed | Weeks 1–2 | DPO sign-off on attributes |
| Security and privacy reviews (parallel) | Weeks 1–6 | Risk register entry accepted |
| Sandbox build and runbook | Weeks 3–5 | Four edge cases passing |
| Change request and scheduling | Weeks 6–7 | Slot outside assessment period |
| Production deployment and leaver test | Week 8 | Deprovisioning demonstrated |
| Pilot cohort live | Week 9 | Support triage published |
Nine weeks is achievable when the reviews run in parallel and the attribute list is agreed early. It becomes five months when the privacy review starts after the sandbox build, which is the most common sequencing error in this work.
If the integration is part of a first deployment rather than a renewal, run it inside a bounded pilot so the technical and pedagogical evidence arrive together — the method is in our guide to running a departmental pilot of an AI writing tool.
To discuss integration requirements against your own LMS and identity estate, request an institutional evaluation.
Frequently asked questions
What is LTI 1.3 and why does the version matter?
It is the current Learning Tools Interoperability specification, which lets an LMS integrate remote tools in a standard way. It improves the authentication security model and introduces a security framework based on OAuth2 and JSON Web Tokens.
What are LTI Advantage services?
A set of services on top of LTI 1.3: Assignment and Grade Services for gradebook columns and grades, Names and Role Provisioning Services for user and role data, and Deep Linking for selecting external content.
Which services should we enable first?
Deep Linking. Add Assignment and Grade Services only if grades must flow back, and require a written justification before enabling Names and Role Provisioning.
Why is service selection a data protection question?
Because Names and Role Provisioning discloses course membership and roles to the tool, and Assignment and Grade Services writes into the assessment system of record. Both change what leaves the institution.
SAML or OpenID Connect?
Whichever your identity provider and the vendor both support well. The consequential decision is the attribute or claims release, not the protocol.
Should access follow the person or the course?
Decide explicitly. Identity-provider entitlement follows the person and uses your existing leaver process; LMS-launch entitlement follows enrolment and disappears with the course.
How long does a first integration take?
About nine weeks with reviews run in parallel. Serialising the privacy review after the build typically pushes it past four months.
When should we deploy?
Between terms or in the first two weeks of a term. Never during an assessment period.
What should we test in the sandbox?
Cross-listed modules, multi-role enrolments, teaching assistants with partial permissions, and a very large cohort. Tidy test courses prove nothing.
What is usually forgotten?
Deprovisioning, and what a returning student sees after an interruption. Both are common in graduate education and both cause licence disputes.
What logs does the integration produce?
Launch logs containing identifiers and course context. Establish where they live and for how long, because they often sit outside the main processing description.
Who should own the rollout?
An academic owner for the outcome, with IAM, the LMS team and the DPO owning their steps. Ownership by IT alone produces an integration nobody asked for.