Case Study - PeopleSoft to Slate Dual Enrollment Integration

This case study examines a real-world integration between PeopleSoft Campus Solutions and Slate by Technolutions (a higher-education admissions CRM). PeopleSoft acts as the HTTP client, pulling dual enrollment applicant data from Slate on a schedule and driving it into Campus Community, matriculation, and term activation. The same pattern applies to any inbound integration where a vendor exposes a query or report as a REST endpoint and PeopleSoft is responsible for ingesting, staging, and integrating the data.

Integration Scope

The population is high school students participating in a dual enrollment program (taking college courses for credit while still in high school) plus a related continuing-education population. The multi-step application lives entirely in Slate:

1. The student fills out a Slate form.
2. The form routes to a parent for additional information.
3. The form routes to a high school counselor for approval.
4. The form routes to institutional staff, who review and mark it ready for import.

Once marked ready, PeopleSoft needs to:

• Ingest the applicant data from Slate.
• Search-match against existing Campus Community records.
• Create or update the person (name, address, phone, email, ethnicity, SSN, birthdate, visa).
• Matriculate into an academic program and plan.
• Term-activate for the admit term.
• Set residency, emergency contact, and a state-assigned student ID.
• Post back the created EMPLID to Slate so downstream Slate users see the PeopleSoft ID.

PeopleSoft is the system of record for the resulting student; Slate is the system of record for the application.

Architecture

The integration is a scheduled pull. Slate does not push into PeopleSoft; PeopleSoft polls Slate.

Two HTTP conversations exist:

• Inbound pull — PeopleSoft issues an HTTP GET to a Slate “Query as a Service” endpoint. The query is a custom Slate report exposed as JSON. A date_submit query string parameter filters on the form-submission date forward.
• Outbound callback — After PeopleSoft creates or updates the person and assigns an EMPLID, a separate REST call posts the EMPLID and integration status back to Slate.

Both calls traverse Boomi, which acts as a pure pass-through proxy. Boomi does not manipulate the data, does not enrich it, does not transform it, and does not route anywhere dynamic. It sits in the middle because the institution has a standing business rule that all inter-system HTTP traffic must flow through the centrally-managed iPaaS — not because this integration needed an iPaaS.

If your organization genuinely needs a single choke point for auditing, credential custody, or firewall traversal, an iPaaS pass-through can be a reasonable cost. If the iPaaS is mandated but not used, the cost is all downside.

See PeopleSoft as HTTP Client for the HTTP client mechanics and HTTP Target Connector for the connector itself.

Why Pull Instead of Push

When you design a vendor integration, the first design question is always: who initiates the conversation?

Slate can push, but the institution chose to pull. The reasons map to general principles:

• The vendor query is the contract. The Slate query is built and tuned inside Slate by the Slate functional team. Changes to the payload, filters, or included fields do not require a PeopleSoft code change as long as the field names stay stable. This is effectively a view-layer contract.
• Retries and recovery are trivial. If PeopleSoft is down, the next scheduled run picks up everything since the last success. There is no queue to drain, no dead-letter handling, no risk of dropped messages on the Slate side.
• The institution controls the cadence. During go-live, the main user runs the process ad-hoc when they know new records are ready. After stabilization, the same code runs on a recurrence. No vendor configuration changes required.

The tradeoff is latency. A pull integration is never real-time. For dual enrollment admissions, where the end-to-end process already spans days of form routing and review, near-real-time is fine.

Idempotency via Vendor GUID

Slate emits a GUID on every applicant record. That GUID is the primary key of the staging table. This one decision makes the rest of the design simple:

• Overlapping date windows are safe. The scheduled run uses a date_submit “from date” that is intentionally conservative (look back further than strictly necessary). Duplicates are collapsed by GUID at insert time.
• Retry is free. A failed run can simply be rerun with the same parameters.
• The operator’s “From Date” parameter does not need to be perfectly managed. If a human schedules the job and leaves the date static, the GUID still prevents double-entry of previously imported students.

A subtle piece of logic handles the recurring case: when the process runs under a recurrence and completes successfully with no more records to process, it auto-advances the “From Date” to the current date minus one day. The minus-one-day overlap is deliberate — duplicates are cheap (the GUID dedups them), missed records are expensive (they require a human to notice and retrigger).

The Staging Table Pattern

The most reusable lesson in this integration is the staging table. Inbound data does not land directly in PS_NAMES, PS_ADDRESSES, PS_ACAD_PROG, and the rest of Campus Community. It lands in a single custom staging table (UM_QCK_ADMT_HDR) with an explicit status state machine and per-integration-step completion flags.

Why a Staging Table

Integrating directly into Campus Community from an inbound REST pull means:

• Every failure is a partial update. If the Person record is created but term activation fails, the student exists in Campus Community in an inconsistent state and there is no clean place to retry from.
• There is no human review surface. Search-match conflicts, data quality issues, and missing fields all have to be handled by code or dropped on the floor.
• The raw vendor payload is lost. When something looks wrong in production six months later, you want to see exactly what Slate sent.

A staging table solves all three. The raw JSON lands in one column, the parsed fields land in their own columns, and each integration step (Person, Matriculation, Term Activation, Residency, Emergency Contact, External ID) gets its own “done” flag and timestamp. A user-facing page lets staff review the record, correct missing data, resolve search-match conflicts, and trigger integration steps individually or all at once.

The Status State Machine

The staging record transitions through a small set of statuses:

The state machine is deliberately small. Every record can be queried and worked from a search page filtered by status. A support team member with no developer access can open an ICOM record, see exactly which step failed, read the error, fix the underlying data, and retrigger.

Per-Step Completion Flags

Each integration step has its own _DONE flag and _DTTM column on the staging record. This is more granular than it needs to be for the happy path, but it pays for itself the moment anything goes wrong. Production support can:

• See at a glance which steps completed for a specific applicant.
• Retrigger only the failed step without re-running the successful ones.
• Mark a step as manually completed when the fix was applied directly in Campus Community outside the integration.

That last capability is critical. An integration that cannot be overridden by a human becomes a production support nightmare. Every real-world integration accumulates edge cases where the cleanest fix is to do the work in the target system directly. The staging record has to be able to catch up to that reality instead of fighting it.

Custom Integration vs. Delivered Quick Admit

PeopleSoft ships a “Quick Admit” process for admitting students with minimal data entry. The integration deliberately does not use it. The custom integration reproduces most of the same steps but reaches Campus Community through Component Interfaces.

What was gained by rebuilding:

• Per-step status tracking, as described above.
• First-class search-match handoff to a suspend queue rather than unconditional create.
• Per-step manual override via the staging page.
• Control over defaults — program, plan, residency, admit term all have sensible defaults when Slate omits them.
• Visibility into the raw inbound payload alongside the processed record.

What was given up:

• Maintenance burden. The integration logic now lives in custom PeopleCode and must be retested across upgrades.
• Delivered Quick Admit enhancements. Future PeopleSoft improvements to Quick Admit do not flow through automatically.

For a high-volume, mission-critical admissions pipeline, the tradeoff favored custom. For a one-off or low-volume integration, using delivered Quick Admit would be a reasonable choice.

Search-Match Handoff

Search-match is the hard problem of any person integration. An asynchronous batch process cannot reliably decide whether “John Smith, DOB 2007-03-12” is the same person as an existing “Jonathan Smith, DOB 2007-03-12” already in Campus Community.

The integration handles this by refusing to guess. Any record with a potential match is moved to status SMAC (Search Match - Suspended) and surfaced to a staff reviewer. The reviewer has two outcomes available:

• Force ID Create — The matches are close but not the same person. The system creates a new EMPLID and proceeds with integration.
• Select a Match — One of the matches is the same person. The staging record is linked to the existing EMPLID and integration proceeds against that person.

Both outcomes are one-button operations on the staging page that chain into “Trigger All Integrations” to complete the remaining steps.

The search-match configuration uses a dedicated parameter (UMASS_SRCH_PARM in this implementation) that is registered against both the batch component and the staging component. Registering it against the component is what allows the delivered search-match UI to be embedded in the custom staging page.

Component Interfaces Used

Every write into Campus Community goes through a Component Interface. No direct SQL, no bypassing PeopleSoft’s business logic. This follows the broader book guidance in Using Component Interfaces for Updates.

Two gotchas worth noting for anyone building similar integrations:

• Ethnicity lives in two places. Campus Community stores ethnicity in both PS_DIVERS_ETHNIC and PS_ETHNICITY_DTL with different CIs and different behavior. Writing to only one of them leaves the data looking correct in one page and missing in another. Plan for both.
• The Hispanic/Latino flag is driven by a derived record. On at least one CI, the “is Hispanic/Latino” checkbox is a level-1 derived field that must be set explicitly; simply populating the ethnic group code is not enough. The delivered behavior is surprising and worth testing early.

The Callback Loop

When the staging record reaches status COMP, PeopleSoft posts the EMPLID back to Slate:

POST /ws/simple/executeSlateUpdateDualEnrollStatus
Content-Type: application/json
Authorization: Basic {{token}}

{
  "persons": {
    "person": [
      {
        "refID": "1233456789",
        "emplID": "987654321",
        "status": "Admission Complete"
      }
    ]
  }
}

Two design notes:

• Decoupled from the inbound pull. The callback fires on any status change that reaches a terminal state, not as an inline step of the inbound flow. A failure to post the callback does not leave the Campus Community record inconsistent; the status can be re-notified later.
• Same proxy, same credential pattern. The callback also routes through Boomi, reusing the same URL Definition and credential infrastructure as the inbound pull. One place to update when credentials rotate.

See JSON Encoding for how to build the outbound payload with PeopleCode’s JsonObject and JsonArray classes, and JSON Decoding for parsing the inbound Slate response.

Environment Isolation

The integration defines one URL Definition per database, keyed by database name:

UM_SLATE_DUAL_ENROLL_{{DBNAME}}

There is a record in each environment (DEV, TEST, QA, PRD) pointing at the correct Slate environment — production Slate for PRD, Slate test for the lower environments. This matters most at database refresh time. When PRD is cloned down to DEV, the URL Definitions come with it, but the {{DBNAME}} keying means DEV looks up UM_SLATE_DUAL_ENROLL_SADEV92 and finds the DEV endpoint, not the PRD endpoint that was just copied in.

This is the same pattern used in the D2L integration case study and for the same reason: a database refresh must never accidentally point a lower environment at production APIs.

Lessons Learned

1. Let the vendor GUID be your primary key. If the vendor emits a stable unique identifier, store it as the primary key of your staging table. Every idempotency problem downstream becomes trivial.

2. Never land inbound data directly into the target’s live tables. Stage it. Track status. Track per-step completion. The cost is one custom table and one admin page; the return is dramatically better production support.

3. Design for human review from day one. Search-match conflicts, data quality issues, and missing required fields are not edge cases — they are the 10–20% of records that consume 80% of the operational time. Build the review surface up front, not after go-live.

4. Give every integration step a manual-override escape hatch. The real world will eventually require a human to fix something outside the integration. The staging record must be able to reflect that reality.

5. Route all writes through Component Interfaces. The work to stand up a CI is small compared to the work of debugging a direct-SQL integration that skipped a piece of delivered business logic. See Using Component Interfaces for Updates.

6. Pull beats push when latency tolerance allows it. You control the cadence, the retry, and the recovery. The vendor’s availability becomes a non-event.

7. Key configuration by database name. URL Definitions, credentials, and feature flags should resolve differently per environment automatically. Database refreshes must not require a post-clone checklist to prevent data bleed.

8. Decouple the outbound callback from the inbound pipeline. Treat “notify the source system” as a separate concern driven by status change, not as an inline step. Failures there should not roll back the work that already succeeded.

9. Test the surprises early. Component Interfaces have behaviors that are not obvious from the page — derived fields, multi-table writes, level-0 versus level-1 placement. Exercise them on real data in DEV before you trust them in PRD.