SIRAS/SIS Integration Troubleshooting & FAQ

Before troubleshooting, identify how the district's integration works.

See SIS Integration Guide for the district's integration model.

Vendor-specific starting points

• Set Up the Aeries–SIRAS Integration
• Aeries–SIRAS Integration Troubleshooting & FAQ
• Aeries API to SIRAS Data Integration
• SIS-to-SIRAS File-Based Demographic Integration

SIS → SIRAS

Examples:

• student demographics;
• school or district enrollment information;
• grade;
• language and English Learner information;
• local identifiers; and
• contacts when enabled.

SIRAS → SIS

Examples:

• special education status;
• eligibility and disability;
• plan dates and program information;
• services; and
• special education exits.

Neither direction

The issue may instead be:

• a local enrollment or SSID problem;
• a record-matching issue;
• a field not included in the integration;
• a local policy or workflow issue;
• a source record that was never created; or
• a reporting transaction that belongs in CALPADS rather than the SIS integration.

Check the applicable process before investigating individual fields.

• Was the source file, API, or vendor feed available?
• Did the scheduled task run at the expected time?
• Was the expected SIRAS log created?
• Did the SIS or vendor generate a completion email, status report, or error file?
• Did the process complete successfully, partially, or fail before student records were processed?
• Did credentials, passwords, API keys, URLs, firewall rules, or hosting arrangements change?

SIRAS scheduled-task logs

When the integration produces a SIRAS log, go to Tools → SIRAS Admin → Scheduled Task Logs and download the most recent applicable file.

Student-level history

For an existing student, review Student Info → Student History for the applicable import identifier and Last Import Date. A current Last Import Date usually means the integration found the student, even when a particular field did not change.

Find the student in the exact source used for the failed run:

• API response or vendor feed;
• district demographic/contact file;
• SIRAS export file;
• SIS completion report; or
• scheduled-task log.

Common reasons the student is absent

• the student was created after the process ran;
• the student is in a different academic-year database;
• the school is excluded or mapped incorrectly;
• the SIS status is excluded from processing;
• the required program or participation indicator is missing;
• the student is inactive in the source system;
• the source query or file does not include that population; or
• the record is outside the date range included in the current export.

Integrations may use several identifiers to locate the correct student:

• SSID;
• Local Student ID;
• legal name;
• birthdate;
• district or school code;
• site code; and
• vendor-specific identifiers.

Common matching outcomes

• Exact match: the intended record is updated.
• No match: the process may create a record when that option is enabled, or log the record for review.
• Close or ambiguous match: the process does not update or create a duplicate because the correct record cannot be determined safely.
• Duplicate source records: the source system or file contains more than one candidate for the same student.
• Dual enrollment: one source record may be processed while a secondary record is ignored according to the integration rules.

The following is the usual authority model. District configuration may vary.

When a value differs

1. Verify what happened in the field.
2. Identify the system that owns the field.
3. Correct the authoritative source.
4. Allow the integration to update the receiving system.
5. Confirm the result.

Some districts use local values that require configuration or mapping.

Common mapping areas

• grade values, including Infant, Preschool, Transitional Kindergarten, Kindergarten, and Grade 12+;
• school codes and school names;
• multiple SIRAS entities located at one SIS campus;
• site codes;
• English Learner and language values;
• race and ethnicity values;
• status or attendance codes excluded from processing;
• unofficial, inactive, summer-school, or “do not use” schools; and
• local identifiers or extended fields.

Review configuration after organizational changes

Mappings should be reviewed when schools open, close, merge, change codes, or when the district changes local SIS values.

Use this correction cycle:

1. Verify the actual field event or value.
2. Identify the authoritative system.
3. Correct the source data, mapping, or configuration.
4. Rerun the process or wait for the next scheduled job.
5. Review the new log or completion report.
6. Confirm the value in both systems.

Do not assume the first error is the only error

A student-level match problem may also prevent service, plan, or contact records from processing. Resolve the parent/student record first, then review whether dependent records still fail.

Track unresolved items

For larger issues, keep a simple list containing:

• student SIRAS ID and SSID;
• source and receiving systems;
• expected and actual value;
• owner;
• next action;
• last test date; and
• resolution status.

Include:

• district or SELPA name;
• SIS or vendor;
• integration type and data direction;
• student SIRAS ID and SSID rather than the student's name in unsecured email;
• date and approximate time of the job;
• whether the issue affects one student, one school, or many records;
• the exact error or warning text;
• the source file, SIRAS log, vendor report, or completion email involved;
• the expected value and the system where it was verified;
• the Last Import Date when available; and
• any recent credential, URL, school, mapping, contact, or SIS change.

Email [email protected].

Return to the beginning of the troubleshooting guide