Recordings Filed by Course and Term, Not by Hand
This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses for records systems, with scope and effort agreed per engagement. Banner runs admissions, registration, finance and records at large universities, and it is the only place that knows which student is in which section of which course this term. Without that, a library of lecture and training recordings is organized by whoever uploaded them.
How it connects
Student, course and term records would come across from Banner, over its APIs or as SFTP flat files, which is the second path large institutions often prefer because it fits an existing nightly batch rather than requiring an API integration to be approved. Those identifiers would arrive as attributes on the media, so a recording belongs to a section and a term rather than to a folder.
Retention is the part that pays for the work. An institution's retention schedule is expressed in terms Banner holds, a term ending or a programme completing, so filing material against those records lets retention follow the schedule instead of being applied by hand years later.
Banner would stay the student information system, and nothing about registration changes. A community MCP server for Banner exists, published openly rather than by Ellucian, so it is not a path the platform treats as shipped; an engagement that wanted to use it would assess it on its own terms first. An engagement would also settle the identity question: whether the platform's accounts come from the same directory Banner feeds, because a roster that does not match the sign-in is worse than no roster.
What you can do together
- File lecture and training recordings against the section and term they belong to, so they are findable next year by someone who was not there.
- Let retention follow the institution's own schedule, expressed in the terms Banner already holds.
- Pull the roster for a course so material is visible to the students actually enrolled in it.
- Assemble what an accreditation review asks for with a workflow reading the record.
A scenario
- ScopingThe engagement would agree whether records arrive by API or nightly SFTP, which fields map to attributes, and how identity lines up with sign-in.
- SetupThe connection would be configured once, with course, section and term mapped onto the media.
- Term startRecordings ingest and attach to their section, visible to the enrolled roster under the library's access control.
- Term endRetention on that term's material follows the institution's schedule because the term is an attribute rather than a memory.
- An accreditation reviewA workflow assembles the recordings for a programme across three years, which would otherwise be a manual search.
What stays where
Banner remains the student information system
Admissions, registration, finance and records stay there, and nothing about them changes.
Course, section and term travel with the media
They arrive as attributes under the library's access control and retention.
The community MCP server is not a shipped path
One exists but Ellucian does not run it, so it would be assessed in an engagement rather than assumed.
Processing runs where you deploy the platform
Shared or dedicated SaaS, your own cloud, or on premises, with a network path or an SFTP route to Banner.
Products and solutions
One Roster Behind the Course and the Video
This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses for records systems, with scope and effort agreed per engagement. Colleague is the student information system used mainly by community colleges and smaller institutions, where one person often runs the integrations and there is no capacity for a system that needs tending. That shapes what is worth building: roster and identity sync, alongside the LTI connection that already carries course content.
How it connects
Student, course and term records would come across from Colleague over its API, arriving as attributes on the media so material belongs to a section and a term. Where Banner's case is usually scale, Colleague's is usually staffing, so an engagement here tends to favour a small scheduled sync that runs unattended over a richer integration that needs watching.
Identity is the half that matters most. Colleague holds who is enrolled, and the platform needs accounts that match, so the engagement would settle whether roster sync rides alongside the institution's existing sign-in rather than creating a second list of people. Where the college already uses LTI to surface course content, that connection is shipped and separate: LTI puts the material inside the course, and this connection tells the library which section and term it belongs to.
Colleague would stay the student information system. Nothing about registration or records changes, and the platform writes nothing back unless a step is scoped for it.
What you can do together
- Keep one roster behind both the course and the recordings, rather than maintaining a second list of students.
- File material against the section and term, so it is retrievable after the people who made it have moved on.
- Let retention follow the college's own schedule, which is written in terms Colleague holds.
- Run the sync on a schedule that needs no attention, which matters where one person owns every integration.
A scenario
- ScopingThe engagement would agree which records sync, how often, and how accounts line up with the college's sign-in.
- SetupThe connection would be configured once against the Colleague API, with section and term mapped onto the media.
- Semester startRecordings attach to their section and are visible to the enrolled roster, with the existing LTI connection surfacing them inside the course.
- UnattendedThe sync runs nightly. Nobody checks it, which is the point.
- Semester endRetention on that term follows the schedule because the term is an attribute on the material.
What stays where
Colleague remains the student information system
Enrolment, records and registration stay there.
LTI and this connection do different jobs
LTI puts material inside a course; this tells the library which section and term it belongs to.
One list of people, not two
Roster sync is scoped to ride with existing sign-in rather than creating a parallel set of accounts.
Processing runs where you deploy the platform
Shared or dedicated SaaS, your own cloud, or on premises, with a network path to Colleague.
Products and solutions
Next step
See it on your own Ellucian instance. We will show the connection made, the data moving and the output, then size it for your deployment.
Request a demonstration or write to sales@vidizmo.ai
sales@vidizmo.ai · vidizmo.ai/integrations/catalog/ellucian