PeopleSoft Campus Solutions ↔ Moodle LMS Roster and Grade Sync

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

Bidirectional synchronization between PeopleSoft Campus Solutions and Moodle LMS requires orchestrating enrollment provisioning via LTI Advantage and grade passback via Moodle Web Services, with PeopleSoft as the system of record. The integration respects PeopleSoft's section-based class model and maps it to Moodle's course structure, using CRSE_ID, CRSE_OFFER_NBR, CLASS_NBR, and STRM as the canonical composite key for section identity.

Implementation Phases

1. Foundation and credentials. Register a LTI 1.3 platform in Moodle (Site Administration → Plugins → LTI → Manage platforms) and generate the deployment ID. Create a PeopleSoft Web Service consumer node and configure WSDL endpoint security using PeopleSoft's INTEGRATION_BROKER password and an SSL-terminated reverse proxy. Test a simple authentication handshake end-to-end.
2. Section and course identity mapping. Build a mapping table in PeopleSoft (custom record or delivered CLASS_MTG_PAT × CRSE_CATALOG join) that produces a Moodle idnumber as {STRM}-{CRSE_ID}-{CRSE_OFFER_NBR}-{CLASS_NBR}. Run the batch job SSR_CLASS_MTG_PAT nightly to keep the map current. Validate that every active section in the current term has a Moodle counterpart before proceeding.
3. Enrollment sync via LTI Advantage. Implement the LTI Names and Roles Provisioning Service (NRPS) consumer in the middleware (Node.js or Python). Pull roster deltas from GET /nrps/{context_jid}/memberships on a configurable schedule (recommended: every 15 minutes). For each membership record, upsert the Moodle user (matching email or id from PeopleSoft EMAIL_ADDR) and assign the role (student → roleid=5, instructor → roleid=3, TA → roleid=4).
4. Grade sync via Moodle Web Services. Enable the gradereport_user and local_wstemplate services in Moodle. Create a Web Services token scoped to grade write. PeopleSoft delivers final grades via stdnt_enrl / STDNT_CRSE_GRADE fields. Map GRADE_POINTS and CRSE_GRADE_OFF to the Moodle grade item using local_o365_grade_passback or a custom SOAP/REST endpoint. Set sync_on_cron = true in the PeopleSoft integration record.
5. Error handling and retry queue. Persist failed sync records in a PeopleSoft staging table (PS_INT_BP_LOG extension). The middleware requeues with exponential backoff (max 3 attempts). Alert on entries older than 48 hours via PeopleSoft Workflow. Log INT_RUN_CNTL_ID and PRCSINSTANCE for audit traceability.
6. Data validation and reconciliation report. Generate a comparison report (PeopleSoft query against SSS_STUDENT_ENRL vs. mdl_user_enrolments) showing matches, orphans, and gaps. Run this for at least two full business cycles before enabling live passback. Require sign-off from the Registrar and LMS administrator.
7. Staged cutover. Enable sync in shadow mode for one term: PeopleSoft drives enrollments but grades are not written to Moodle. After one grading cycle, switch to live passback for pilot courses (recommend 3–5 sections). Monitor mdl_grade_items and ps_sf_grade_api logs daily.
8. Full production cutover. Flip the integration to production after pilot reconciliation passes. Maintain a read-only fallback: grades can still be entered manually in Moodle for 30 days post-cutover to catch data-quality issues. Archive the PeopleSoft INT_BP logs for 90 days.

Field Mapping

Edge Cases

• Mid-term drops. When a student drops after a grade is already passed back, PeopleSoft sets ENRL_STATUS_CODE = 'D'. The middleware must delete the Moodle enrollment AND remove any existing grade row in mdl_grade_grades to avoid a stranded grade after re-enrollment.
• Name changes. PeopleSoft may update NAME without changing EMPLID. The middleware must upsert on idnumber, not re-create the user, or duplicate accounts will proliferate in Moodle.
• Grade mode changes. If CRSE_GRADE_BASIS switches from Letter to Pass/Fail mid-term, the grade scale changes. Moodle's grade item must be updated via grade_item_update before the next passback, or grades will be stored against the wrong scale.
• Concurrent section enrollment. A student enrolled in two sections of the same course (e.g., lecture + lab) must receive two separate mdl_user_enrolments rows and two separate grade entries keyed to the correct CLASS_NBR.
• Non-term courses. Continuing education or non-standard terms where STRM is 9999 or blank require a separate mapping bucket; hard-code these into the configuration table to prevent empty idnumber values.
• Re-runs and repeat enrollments. When a student repeats a course (same CRSE_ID, new CLASS_NBR in a new term), a new Moodle enrollment must be created; the old grade item is preserved but marked hidden = 1 in Moodle per institutional repeat-policy rules.

Cutover

Cutover is reversible by disabling the Web Services token and reverting LTI NRPS to manual provisioning. Before going live, run a full reconciliation comparing COUNT(*) of mdl_user_enrolments against STDNT_ENRL filtered by current term; the delta must be zero (allow for W-withdrawn students counted in PeopleSoft but not in Moodle, which is correct). Freeze the integration configuration record (INT_CONFIG_CD) until the first grading cycle completes. Schedule a 48-hour rollback window post-go-live: if more than 5% of grade passback calls fail, or if the reconciliation report shows unmatched grades, re-enable manual entry and re-run the PeopleSoft SCC_SF_GRADE_LOAD batch to restore PeopleSoft as the sole authoritative grade store until the root cause is resolved.