SIS → Slate admissions CRM sync

Admissions lives in Slate; the record of truth for enrolled students lives in the SIS. When the two drift, applicants fall through the gap between "admitted" and "enrolled". This sync moves applicant and decision data into the SIS and enrolment status back into Slate, keyed consistently, so both sides tell the same story.

Free reference snippet

Yours to use

A working piece from this integration — no sign-up. The full build handles the edge cases, safeguards, and cutover.

# Sync a final admission decision from SIS to Slate
# Slate REST API — POST /api/decision

PUT https://campus.example.edu/api/application/{slateAppId}/decision

{
  "decision": "Accept",                              // SIS: DEC_FINAL_CODE
  "decisionType": "final",
  "timestamp": "2024-05-15T09:30:00Z",
  "term": "2025 Fall",
  "degree": "B.A.",
  "major": ["UNDECLARED"],                       // SIS: MAJ_1_CODE
  "sendNotification": true,
  "sendToApplicant": true,
  "externalId": "SIS-2024-0078234"
}

# Lookup Slate App ID by SIS student ID before calling decision endpoint
GET https://campus.example.edu/api/query?
    q=Select * from Applications where externalId = '{sisPersonId}'

SIS Field	Slate Field	Notes
`PERSON.SIS_ID`	`externalId`	Join key — persist on app creation
`APP.DEC_FINAL_CODE`	`decision`	"Accept", "Deny", "Waitlist", "Defer"
`STU.ADMIT_TERM`	`term`	Use Slate term lookup key
`STU.ENROLL_STATUS`	`Enrollment Status`	Sync via material status endpoint

Implementation pathway

Step by step

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

Syncs applicant records, decision outcomes, and confirmed enrolment from the Student Information System into Slate so the admissions office and registrar share a single authoritative view. The integration runs on a scheduled batch pull from the SIS export tables, transforms records through a staging schema, and upserts into Slate via the Reader application or direct API calls.

Implementation Phases

Discovery and requirements — Catalog every SIS table and view that holds applicant, decision, and enrolment data. Confirm the Slate dataset, record type, and application scope where records land. List business rules: who triggers a decision push, what enrollment statuses map, and whether historical records need backfill.
Schema mapping workshop — Align SIS field names to Slate export column names. Identify Slate lookup keys (PersonID, ApplicationID) and the SIS surrogate keys used to match records. Document one-to-one mappings versus transformation logic (e.g., status codes to Slate decision types).
Authentication and endpoint setup — Register the integration service account in Slate Admin. Obtain the API key or OAuth2 client credentials. Validate connectivity by issuing a test read against the target dataset. Confirm inbound IP allowlisting if the SIS network is restricted.
Staging and transformation build — Create a staging schema (e.g., stg_slate_sync) with tables mirroring the SIS export layout. Build ETL logic: filter records changed since the last sync run, apply de-duplication (prefer latest SIS record on key collisions), and map decision codes to Slate DecisionType and DecisionStatus values.
Slate Reader / API write pipeline — Configure a Slate Reader job to pull from the staging schema, or build REST calls to /api/rpc/batchUpsert (verify endpoint name in your Slate version). Log every upsert attempt with a correlation ID linking back to the SIS source row.
Testing in non-production — Run the pipeline against a copy of the SIS export. Verify counts in Slate match expected outcomes. Test null-handling, truncated names, and duplicate LookupID scenarios. Validate decision status transitions in Slate UI.
UAT with admissions staff — Load real (masked) applicant records. Have admissions verify decision descriptions, enrollment badges, and that no unintended field overwrites occurred. Sign off on field mapping and error thresholds.
Production cutover plan — Schedule the initial full-load during a low-activity window. Enable the scheduled delta sync afterward. Establish monitoring dashboards for row counts, latency, and API error rates.

Field Mapping

SIS Field	Slate Identifier / Column	Notes
`applicants.person_id`	`PersonID` (Slate `Person` key)	Primary join key; maps to Slate `Lookup ID`
`applicants.first_name`	`First Name`	Direct map; apply title-case before load
`applicants.last_name`	`Last Name`	Direct map; strip leading/trailing spaces
`applications.application_id`	`ApplicationID` (Slate `Application` key)	Used for decision linkage; must be stable across loads
`decisions.decision_code`	`DecisionType`	Transform SIS codes to Slate enumerated values (e.g., `ADMIT`, `Deny`)
`decisions.decision_date`	`DecisionDate`	ISO 8601 format; push null if not yet decided
`enrollment.status_code`	`EnrollmentStatus` (custom Slate field)	Requires a pre-created Slate dataset field; values: `Confirmed`, `Withdrawn`, `Deferred`
`enrollment.program_code`	`Program`	Matches Slate term/program lookup; trim to 50 characters

Edge Cases

Duplicate applicants — A person may appear twice in SIS with variant spellings; Slate's de-duplication on First Name + Last Name + Date of Birth must be configured before the first load or records will split.
Decision rollback — If SIS voids a decision after Slate reflects it, the integration must push the void status; a silent omission creates a stale admit in Slate.
Enrollment status before decision — SIS sometimes sets Enrolled before the formal decision record exists; the pipeline must guard against linking enrollment to a missing ApplicationID.
Name truncation — SIS fields may exceed Slate's column width; truncate at the boundary rather than rejecting the batch.
Null DecisionDate — Slate rejects a decision record without a date; default to the record creation timestamp in SIS when the field is null.
API rate limits — Slate enforces concurrent request caps on bulk writes; the pipeline must implement chunking (recommend 200 rows per batch) and respect Retry-After headers.

Cutover

Begin with a full historical load during a maintenance window, then switch to delta-sync on the next scheduled cycle. Before going live, validate that row counts in Slate match SIS counts for every application_id in the prior 12 months. Keep the SIS export tables readable for a 48-hour rollback window; if Slate record counts diverge, run a reconciliation query joining on PersonID and ApplicationID, and re-run the batch for the affected application_id set. Once reconciled, disable the rollback path and promote the integration to steady-state monitoring with alerts on sync lag exceeding 15 minutes.

What a full implementation includes

Canonical mapping between Student Information System and Slate (Technolutions), to the field level.
The edge cases that corrupt data at cutover — identified, handled, and tested.
Production-safe rollout: reversible, phased, with reconciliation checks.
Handover documentation your team can operate from.