Unit4 Student Information System to PeopleSoft Campus Solutions Bidirectional Sync

How we'd take this from discovery to a production-safe cutover — the phases, the canonical mapping, and the edge cases that bite.

Implement a bidirectional sync between Unit4 Student Information System and Oracle PeopleSoft Campus Solutions, exchanging student demographics, course enrollments, and grade data via middleware orchestrations with conflict resolution for overlapping source-of-truth scenarios.

Implementation Phases

1. Discovery and API Surface Analysis — Enumerate PeopleSoft Component Interfaces (CIs) and REST/SOAP endpoints for PS_STUDENT_TABLE, PS_PERSON, PS_STDNT_CARGR, and PS_ENROLLMENT. Map Unit4 entity endpoints and webhook subscriptions. Document authentication requirements (OAuth 2.0 for Unit4; Integration Broker security for PeopleSoft). Identify data ownership boundaries: which system holds authoritative record for each entity type.
2. Data Model Alignment and Canonical Schema — Define a canonical student record schema covering STUDENT_ID, PERSON_NAME, ENROLLMENT_STATUS, GRADE_VALUE, and associated effective-dates. Resolve type mismatches (e.g., PeopleSoft uses EMPLID as the primary key; Unit4 uses student_uuid). Create a cross-reference table mapping each system's surrogate keys to a shared identifier.
3. Middleware Orchestration Design — Select integration middleware (e.g., MuleSoft, Dell Boomi, or Apache Camel) capable of handling bidirectional event streams. Design publish/subscribe topics: student.demographics.changed, enrollment.created, grade.posted. Implement idempotent message processing using correlation IDs to prevent duplicate inserts. Configure dead-letter queues for failed transformations.
4. Unidirectional Pilot: Unit4 → PeopleSoft — Sync student demographics from Unit4 into a staging table on the PeopleSoft side (e.g., PS_INT_STG_STUDENT). Validate data integrity before posting to production tables via Component Interface. Run parallel mode for 30 days, comparing record counts and field-level diffs. Do not enable bidirectional flow until error rate drops below 0.1%.
5. Unidirectional Pilot: PeopleSoft → Unit4 — Mirror the above in reverse direction. Focus on grade data sync where PeopleSoft is likely authoritative for academic records. Use PeopleSoft's Integration Broker to publish outbound messages; consume via Unit4 REST API. Reconcile grade records by CRSE_ID, TERM, and EMPLID composite key.
6. Bidirectional Conflict Resolution and Cutover — Implement a priority matrix: if both systems modify the same record within the polling window, apply last-modified-wins by comparing LASTUPDDTTM (PeopleSoft) against updated_at (Unit4). For grade conflicts, enforce PeopleSoft as authoritative and log discrepancies. Execute a big-bang cutover with a 48-hour freeze window, followed by a 14-day hypercare period with hourly reconciliation reports.

Field Mapping

Edge Cases

• Duplicate Student Creation — If Unit4 creates a student and PeopleSoft creates the same student independently before sync runs, the cross-reference table will have conflicting entries; resolve via manual de-duplication workflow with admission decision review.
• Concurrent Grade Updates — An instructor posts a grade in PeopleSoft while an academic office updates the same grade in Unit4 within the same sync window; the last-modified-wins logic may silently overwrite a valid correction.
• Enrollment State Drift — A student drops a course in Unit4 but the sync has not yet propagated; if the student adds a different course in PeopleSoft during the lag, enrollment counts become inconsistent until reconciliation runs.
• Term Boundary Transitions — When a new term begins, historical enrollment records must remain immutable in PeopleSoft but may be archived differently in Unit4; syncing active-only flags can corrupt the academic history audit trail.
• Null or Default Grades — PeopleSoft uses blanks or placeholder codes for incomplete grades; if Unit4 sends null, the middleware must map explicitly to PeopleSoft's placeholder rather than clearing the field.

Cutover

Cutover requires a full reversible path. Before the go-live window, export a snapshot of both systems' student, enrollment, and grade tables. Deploy the sync middleware in "shadow mode" for 72 hours prior: all transformations execute but writes are suppressed, and a diff report highlights any records that would diverge. At cutover, enable writes in a graduated ramp: first 10% of active students for 4 hours, then 50% for 8 hours, then 100%. Maintain a rollback script that re-imports the pre-cutover snapshots and disables the middleware listeners. Run reconciliation queries hourly for the first 48 hours, comparing aggregate counts by term, enrollment status, and grade distribution histograms. If reconciliation error rate exceeds 0.5%, pause the sync and investigate before resuming.