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.
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.
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.
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
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.
Contact VIDIZMO
sales@vidizmo.ai
+1 571-969-2180
vidizmo.ai