A student information system integration is what lets a university website show course catalogs, class schedules and program requirements without anyone retyping them. The data lives in Banner, PeopleSoft, Workday or an in-house system; Drupal reads it, shapes it and publishes it. In this article we set out the three patterns that integration can follow, how each of the major platforms exposes its data, which system should own what, and the failure points to plan for before the first term rollover.
Most descriptions of this topic stop at a single sentence: Drupal integrates with student information systems. That is true and not very useful. The questions a web team actually faces are different. Does course data get copied into Drupal or read live? What happens when the registrar retires a section mid-term? Where does the marketing copy for a program live if the official description is in the SIS? Which of the two systems is right when they disagree? Below we work through those questions with the platforms most universities run.
What a student information system integration actually does on a university website
The student information system is the institution's system of record for academic data. It holds the course catalog, the schedule of classes, program and degree requirements, enrollment, grades, transcripts and the academic calendar. Nothing on the public website should contradict it.
The website, in turn, is where most of that data is actually seen. Prospective students read program pages. Current students check when a section meets. Advisors look up prerequisites. When the website and the SIS drift apart, the website is wrong, and the people who notice are the ones the university least wants to disappoint.
An integration removes the retyping between the two. In practice it covers a fairly short list of data types, and it helps to name them because each one behaves differently:
- Course catalog: course codes, titles, credit values, descriptions and prerequisites. Changes a few times a year, tied to a catalog year.
- Schedule of classes: sections, meeting times, rooms, instructors and seat counts. Changes daily during registration.
- Programs and requirements: degrees, concentrations and the rules that connect courses to them. Changes rarely but with formal approval.
- Academic calendar and terms: term codes, add and drop deadlines, holidays. Small, stable, and referenced by everything else.
- Student-specific records: a particular student's schedule, holds, degree progress. Personal data, only ever shown to that student after authentication.
The first four are institutional data and can appear on public pages. The last one is personal data and follows different rules, which we come back to below.
Three integration patterns and when each one fits
Almost every SIS integration on a Drupal site is one of three patterns, and choosing the wrong one is the most common source of later trouble. The deciding factors are how often the data changes, how many people read it, and whether it belongs to an individual.
Scheduled import for catalog and program pages
The SIS exports course and program data on a schedule, typically nightly, and Drupal imports it into ordinary content: a course content type, a program content type, taxonomy terms for subjects and terms. Drupal core's Migrate API handles this, with the Migrate Plus and Migrate Tools contributed modules adding JSON, XML and CSV sources and the tooling to run and roll back imports. The Feeds module is the lower-code alternative for simpler feeds.
Once imported, the data behaves like any other Drupal content. It is searchable, cacheable, translatable and can be referenced from other pages. Editors can attach fields the SIS does not have, such as a marketing summary, a hero image or testimonials, without touching the official record. The University of Dundee built its course pages this way as custom entities, indexed them with Search API alongside people and schools, and shipped the undergraduate course section as its first release in July 2019.
This pattern fits data that changes on a known cycle and is read by many people. It does not fit anything that changes hourly, because a nightly import will always be behind.
Live read for availability and schedules
Here nothing is copied. Drupal queries the SIS API when a page is requested and renders the result. The External Entities module is built for exactly this: it defines an entity type whose storage is a remote REST endpoint rather than the Drupal database, so the remote data can still be used with Views, view modes and field formatters. Views Remote Data offers a lighter route when only a listing is needed.
Live read is the right answer for seat counts, section status and anything else where a stale value misleads. It carries two costs. Every page view becomes an API call unless you cache carefully, and the website's uptime now depends on the SIS API's uptime. A short cache with a defined time to live, and a graceful fallback message when the API is unreachable, are not optional extras. Without them the first registration day takes the website down along with the SIS.
Authenticated lookups for student-specific data
The third pattern covers the student portal: my schedule, my holds, my degree audit. The data is fetched on demand for the person who is logged in, shown once, and not stored in Drupal at all. Identity comes from the campus single sign-on; the student's identifier from that session is what the SIS query is keyed on.
This pattern depends on identity being solved first, because the wrong identifier returns the wrong student's record. We covered the options in SSO integration with SAML, Shibboleth, LDAP and CAS. Once that is in place, the SIS call itself is usually a single request against a person or student endpoint, made server-side with the institution's API credentials, never with anything exposed to the browser.
Some universities decide that this layer belongs in the SIS vendor's own self-service product rather than on the Drupal site, and link out to it instead. That is a legitimate choice, and often the cheaper one. Drupal earns its place in the portal when the institution wants to combine SIS data with content, news, events and services the SIS knows nothing about.
Connecting Drupal to the major platforms
Each vendor exposes its data differently, and the differences shape which pattern is practical.
Ellucian Banner and Colleague through Ethos
Ellucian's recommended route for third-party integration is Ethos, a unified REST and JSON layer that sits above both Banner and Colleague. Ethos presents a common data model, so a course, a section or a person has the same shape whichever product sits underneath, and every record carries a GUID rather than a product-specific ID. Ethos is hosted regionally, with separate endpoints for the United States, Canada, Europe and Asia-Pacific, which matters for institutions with data residency requirements.
For Drupal, this means one set of resource definitions works for both Banner and Colleague campuses, and the External Entities module can map Ethos JSON to fields with its JSONPath mapper. Access is granted per resource and per field on the Ellucian side, so the first task of the project is usually agreeing with the registrar's office which resources the website needs, not writing code. Older Banner campuses without Ethos still expose direct APIs and database views; those work, but each integration becomes campus-specific.
PeopleSoft Campus Solutions
Oracle's Campus Solutions exposes data through Integration Broker, its messaging and web services layer, using REST or SOAP. Course catalog and schedule data come from the Student Records module, and the concept that catches most integrators is effective dating: a course does not have one description, it has a history of descriptions each valid from a given date, and the query has to ask for the right one for the catalog year being displayed.
This is why scheduled import suits PeopleSoft catalog data well. The import can resolve effective-dated rows once, nightly, and store the current version. Doing that resolution on every live request is wasteful. Live read is still the right pattern for section availability, where the value is a single current number.
Workday Student
Workday exposes REST and SOAP web services and, for reporting-style extracts, custom reports that can be published as data feeds. In practice many Workday Student integrations are built on those report feeds: the registrar defines a report containing exactly the course and section fields the website may see, and Drupal consumes it on a schedule. That approach keeps the data contract explicit and puts control of what leaves the SIS with the people who own it.
Workday's term and academic period model differs from Banner's and PeopleSoft's, so field mapping deserves a design session of its own rather than being assumed from a previous project.
In-house and regional systems
Plenty of universities run a system of their own, a national platform or a regional vendor product. The pattern does not change; only the transport does. If the system has an API, External Entities or a custom migrate source plugin can consume it. If it can only produce files, a scheduled CSV or XML drop to an SFTP location and a Migrate import is a perfectly respectable integration and is often more reliable than a fragile API. The point is to agree the data contract and the schedule, then keep both stable.
Which system owns the data
The most important decision in the project is not technical. It is a statement of who owns which fields.
The SIS owns everything academic and official: course codes, titles, credits, prerequisites, requirements, meeting times, term dates. Drupal never edits those; it displays them. If a course description on the website is wrong, the fix happens in the SIS and flows through on the next import.
Drupal owns everything the SIS was never designed to hold: the program's marketing narrative, faculty quotes, career outcomes, imagery, calls to action, translations and search engine metadata. Those fields live on the Drupal side, attached to the imported record but stored separately from it, so an import never overwrites an editor's work.
Writing this down as a field-by-field table, agreed by the registrar and the web team before anything is built, prevents the two most common arguments later: an editor who changed a credit value on the website and was overwritten overnight, and a registrar who cannot understand why a course they retired is still appearing on a landing page someone hand-built.
Write-back from Drupal to the SIS, where a web form creates or changes an SIS record, is possible through Ethos and Integration Broker, but it belongs to a different risk category. Most institutions route application and enrollment actions through the SIS vendor's own products or an admissions CRM and keep the website read-only against the SIS. That is the sensible default.
Student privacy in the integration layer: FERPA and GDPR
The moment an integration touches student-specific records it is handling regulated data. In the United States, FERPA distinguishes education records, which require consent to disclose, from directory information such as name and program, which an institution may release unless the student has opted out. In the European Union and the United Kingdom, GDPR applies to any personal data, and the principles of purpose limitation and data minimisation govern how much of it the website may fetch.
Three rules keep a Drupal integration on the right side of both regimes:
- Institutional data on public pages, personal data only behind authentication. Catalogs and schedules are institutional. A student's own schedule is personal.
- Fetch personal data on demand and do not store it. The authenticated lookup pattern exists for this reason. No student record should sit in a Drupal table or in a page cache that another user could hit.
- Request only the fields the page uses. Ethos and Workday report feeds both let the institution scope access per field. Scoping it narrowly is the cheapest compliance control available.
Logging which system account fetched what, and when, closes the loop for audit. We covered the broader obligations in achieving GDPR compliance with Drupal; the integration layer is where several of them become concrete.
What breaks in practice and how to plan for it
Integrations rarely fail on launch day. They fail at the first event the design did not anticipate. These are the ones that recur.
- Term rollover. The SIS opens a new term while the website is still showing the old one as current. Model terms explicitly in Drupal and drive the notion of "current term" from the SIS calendar, not from a hard-coded date.
- Retired and merged courses. A course disappears from the export but its Drupal page, with its inbound links and search ranking, is still live. Decide in advance whether the import unpublishes it, archives it with a notice, or redirects it to a successor.
- Effective-dated changes. A description valid from next catalog year appears on this year's page because the query did not filter by date. This is a PeopleSoft classic but the concept exists everywhere.
- Cache invalidation. Live-read data is cached for performance, then a seat count stays at zero for an hour after seats opened. Set the time to live per data type, and shorten it during registration windows.
- API limits and outages. A homepage block that calls the SIS on every request will exhaust a rate limit on the first busy morning. Cache aggressively, degrade gracefully, and never let an SIS outage produce a blank page.
- Identifier mismatches. The SSO identity uses one identifier and the SIS another. Agree the mapping before building the portal, and test it with real accounts including edge cases such as staff who are also students.
None of these is exotic. A one-page runbook covering them, written before launch, is worth more than most of the code.
How deep should the integration go?
Not every university needs all three patterns, and building portal functionality that nobody uses is a common way to overspend.
A brochure-level site needs only program pages, and those can be maintained by hand if the program list is short and stable. A catalog-level site needs the scheduled import; that is where most of the value sits for most institutions, because it removes retyping across hundreds of pages. A portal-level site adds authenticated lookups and is only worth it when the institution wants a single front door combining SIS data with everything else the campus publishes. The cost difference between the tiers is substantial, and our TCO analysis of open-source versus licensed systems sets out how to weigh implementation effort against licence savings.
It also helps to be clear about what the SIS integration is not. It is not the learning management system integration. The SIS records that a student is enrolled in a section; the LMS delivers that section. The two integrations move different data, usually through different APIs, and are best scoped as separate pieces of work even when they land in the same term.
Planning your first integration
The technical work in an SIS integration is smaller than it looks. The larger part is agreement: which fields the website may read, which system owns each one, how often each type refreshes, and what happens at term rollover. Universities that settle those questions with the registrar first tend to build the integration once. Universities that start from the API documentation tend to build it twice.
The Drupal platforms that the Drupal4edu team at Drupart has built for institutions such as Sabanci University, METU and Yildiz Technical University are designed around exactly this kind of integration layer, where the website reads from the institution's systems of record rather than duplicating them. You can read more about our approach on the Drupal for education page.
Frequently asked questions about Drupal SIS integration
Can Drupal integrate with Ellucian Banner?
Yes. The current route is Ellucian Ethos, a REST and JSON layer that presents Banner and Colleague data in a common model with GUID identifiers. Drupal reads Ethos resources either on a schedule, using the Migrate API to import courses and programs as content, or live, using the External Entities module to render remote records without storing them. Access is scoped per resource and per field on the Ellucian side, so the registrar's office controls exactly which data the website can see. Older Banner installations without Ethos can still be integrated through direct APIs or database views, but each such integration is specific to that campus.
Does Drupal store student data when it integrates with a SIS?
Only if the integration is designed that way, and for personal data it should not be. Institutional data such as course catalogs and class schedules is normally imported into Drupal so it can be searched, cached and enriched with marketing content. Student-specific records such as an individual's schedule or holds should be fetched on demand for the authenticated student, displayed, and discarded. No student record needs to sit in a Drupal table or in a shared page cache, and keeping it out of both is the simplest way to satisfy FERPA and GDPR at the same time.
How often should course data sync between the SIS and the website?
It depends on the data type. Course catalog and program data change a few times a year and a nightly import is more than enough; some institutions run it weekly. Schedule-of-classes data changes daily during registration, so either a more frequent import or a live read with a short cache is needed. Seat counts and section status should be read live during registration windows. Promising real-time synchronisation for everything is a mistake: it costs performance and reliability and buys nothing for data that only changes with the academic calendar.
What is the difference between SIS integration and LMS integration?
They move different data. The student information system is the system of record for enrollment, courses and academic history. The learning management system, such as Moodle or Canvas, is where teaching happens: materials, assignments and grades in progress. An SIS integration brings catalog, schedule and enrollment data to the website. An LMS integration usually concerns single sign-on and linking students from the website into their course space. We describe the LMS side in Moodle and Drupal integration. The two projects are best scoped separately even when they share a launch date.
Is a Drupal SIS integration FERPA compliant?
Compliance is a property of the whole design, not of any software. A Drupal integration can be built to meet FERPA obligations by keeping education records behind authentication, fetching them on demand rather than storing them, requesting only the fields a page uses, and logging which system account accessed what. Directory information such as course listings and instructor names may appear publicly unless the institution's policy or a student's opt-out says otherwise. The registrar's office, not the web team, decides which fields fall into which category, and that decision should be documented before the integration is built.