Salesforce SIS Integration Patterns: Banner, Colleague, Jenzabar, PeopleSoft

The student information system stays the system of record. Salesforce integrates with Banner, Colleague, Jenzabar, and PeopleSoft only through supported APIs or a hub the institution owns, never through direct database writes. Catalog flows from the SIS to Salesforce, enrollments and payments flow back, and learner identity flows both ways. ElevateActual agrees the design with the SIS owner first.

What Is the One Rule?

Every integration between Salesforce Education Cloud and a student information system follows one rule: the SIS remains the system of record for the student, the term, the course, the enrollment, and the account balance. Salesforce reads from it and writes to it only through interfaces the SIS vendor supports or the institution has contracted for. Nobody writes to a Banner, Colleague, Jenzabar, or PeopleSoft table directly, no matter how convenient the credentials look.

The reason is not purity. Direct writes bypass the validation the SIS runs, break when the vendor patches the schema, void vendor support, and leave the registrar unable to explain where a record came from. UNE Online's storefront runs beside Banner on exactly this basis: Banner is the system of record, integrated only through supported Banner APIs, never direct database writes.

What Flows Each Way?

Three kinds of data cross the boundary, each with a natural direction.

• Course catalog, from the SIS to Salesforce. Programs, courses, sections, terms, instructors, and seat counts originate in the SIS and land on LearningProgram, LearningCourse, CourseOffering, and AcademicTerm. Noncredit offerings that exist only in Salesforce are fine; the ones the SIS knows are mastered there.
• Enrollments and payments, from Salesforce to the SIS. When a learner applies, registers, or pays on a Salesforce storefront or portal, the resulting IndividualApplication, CourseOfferingParticipant, and order records are written back so the SIS can post the enrollment and finance can post the payment.
• Learner identity, in both directions. A new learner is usually created in Salesforce first, by an inquiry or a guest checkout. The SIS issues the student ID, which comes back to the Person Account and becomes the shared key. Why that key matters is covered in the Education Cloud data migration checklist.

Write these three flows down with their field lists before anyone opens a tool. Most integration overruns come from a fourth flow someone assumed and nobody specified.

How Does Banner Integrate?

Banner institutions have two supported paths. The first is Ellucian Ethos, the vendor's integration platform, which exposes Banner data through Ethos APIs and a common data model. The second is an integration hub the institution already owns and operates. We have worked with institution-contracted hubs such as Axiom and with iPaaS tools such as Jitterbit, in each case as the institution's tool rather than ours. Campus IT owns the hub; our work is the Salesforce side: the objects it writes to, the external IDs it matches on, and the Flows that react when a record arrives.

The Banner-specific trap is term and section identity. Banner's term codes and course reference numbers are the keys the registrar thinks in, so they belong in external ID fields on AcademicTerm and CourseOffering, exactly as Banner formats them.

How Does Colleague Integrate?

Colleague institutions use either Colleague's own web API connector or Ethos, since Colleague and Banner share the Ethos platform. The pattern matches Banner: catalog in, enrollment and payment out, identity both ways, with the institution's integration team owning the connector and ElevateActual owning the Salesforce side. The Colleague-specific trap is the person record. Colleague's person ID is often issued at inquiry, so decide whether Salesforce creates the person and receives the ID, or Colleague creates the person and Salesforce receives the record. Either works; doing both produces duplicates.

How Does Jenzabar Integrate?

Jenzabar institutions most often integrate through staging tables with scheduled ETL in both directions. The institution's database administrator provisions tables beside Jenzabar that Salesforce may read and write; scheduled jobs on the Jenzabar side move data between those tables and the live schema, applying Jenzabar's own validation on the way in. Salesforce never touches the live tables.

This is the pattern we built for a health-sciences university with graduate and doctoral programs that moved recruitment and admissions off TargetX onto standard Education Cloud. Admitted students flow from IndividualApplication into the staging tables, Jenzabar's jobs pick them up, and the admissions office no longer re-keys admits. The Jenzabar-specific trap is schedule drift: if the Salesforce job runs before the Jenzabar job finishes, Salesforce reads yesterday's data and nobody notices for a week. Agree the schedule, add a run timestamp to each table, and have Salesforce check it.

How Does PeopleSoft Integrate?

PeopleSoft Campus Solutions integrates through Integration Broker, its web services layer, or through MuleSoft, which Salesforce owns and many PeopleSoft campuses already license. Integration Broker exposes component interfaces as services; MuleSoft gives the integration team a managed layer with connectors for both ends. The PeopleSoft team owns the services and their security, and ElevateActual owns the Salesforce objects and automation they map to. The PeopleSoft-specific trap is effective dating: PeopleSoft keeps history as effective-dated rows, and a naive integration sends every row. Decide which effective date Salesforce needs, usually the current one, and filter at the source.

Where Does Canvas Fit?

Canvas is the learning management system, and in most designs it is an enrollment target rather than a source. Once a learner is enrolled, in the SIS for credit or in Salesforce alone for noncredit, Canvas needs a user and a course enrollment. Canvas supports this through its REST API and its SIS import, and the LMS administrator owns both. For noncredit programs that never touch the SIS, a Flow on CourseOfferingParticipant can trigger the Canvas enrollment directly, one reason we keep enrollment automation in Flow, as described in Flow-first automation for enrollment.

Which Path, Who Owns It, and How Fast?

Latency is a design choice, not a product limit; every path below can be scheduled or made near real time if the institution's team can operate it that way.

What Does the Storefront Need From the SIS?

A continuing education storefront on Salesforce Commerce raises the stakes, because money is involved. We build what we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, connected to Education Cloud so that checkout creates the enrollment. The storefront needs catalog and seat counts from the SIS; the SIS needs the enrollment and the payment reference back. The campus payment processor, TouchNet or Transact CashNet, stays where it is and the storefront integrates with it. The storefront-specific trap is seat counts: a nightly cache oversells a popular section by the end of a registration day, so bring seat counts in near real time or hold a Salesforce-side reservation the SIS confirms.

What If the Real-Time Step Is Not Ready at Go-Live?

It often is not. The Salesforce build finishes on schedule and the campus integration team is three projects deep. The interim pattern we use is a daily file push that the institution's IT runs: an export from Salesforce to a secure folder each morning, an import into the SIS by the campus team, and a return file with student IDs and posting results the next day. It is not elegant. It is supportable, auditable, and keeps the SIS as system of record on day one.

Two conditions make it safe. The file layout is the field list the real-time integration will use, so nothing is redesigned later. The retirement date is in the project plan with an owner, because an interim file that works will otherwise run for years. University of Denver's DU Learning Exchange is launching after DU completes its identity and SIS integration steps, the other acceptable answer: sequence the launch behind the integration. Portal implications are covered in building an applicant portal on standard Education Cloud.

What to Agree With the SIS Owner Before Building

We work through this list with the registrar, the SIS administrator, and campus IT before building. Each item prevents a specific late surprise.

1. System of record for each entity: student, term, course, section, enrollment, payment, noncredit offering. Prevents two systems both owning the enrollment.
2. The identity key and who issues it. Prevents duplicate learners.
3. The supported interface and its version, with the vendor documentation and the institution's license. Prevents a design that depends on an interface nobody has paid for.
4. The field list per flow, with transformations. Prevents the fourth flow nobody specified.
5. Schedule and latency per flow, including what happens when a job fails and who is paged. Prevents schedule drift.
6. Error handling and reconciliation: where rejected rows go, who reviews them, and the daily count proving both sides match. Prevents silent loss.
7. A test SIS environment with realistic terms and sections. Prevents testing against production.
8. Security and credentials: a named integration user, least privilege, a rotation owner. Prevents a shared admin password in a Flow.
9. The interim plan and its retirement date. Prevents a permanent interim.
10. Who supports it after launch, named on both sides. Prevents the integration becoming nobody's job.

Treat the signed list as a living document. Integrations are never done done: the SIS gets patched, the term structure changes, and the list is where the next change gets recorded.

Questions We Hear