You are using an unsupported browser. Please update your browser to the latest version on or before July 31, 2020.
close
You are viewing the article in preview mode. It is not live at the moment.
Home > Support Center > SIS Integration > SIS Integration Troubleshooting & Ongoing Monitoring
SIS Integration Troubleshooting & Ongoing Monitoring
print icon
Start with the data direction and the evidence from that job.
When an SIS integration does not behave as expected, first identify whether the issue is SIS/Aeries → SIRAS, SIRAS → SIS/Aeries, or the SFTP connection itself. Each direction has its own source data, log, schedule, and completion evidence.
Do not change a verified record just to make two systems agree.
Determine what actually happened, identify which system is authoritative for the field, correct the source when necessary, rerun the appropriate process, and verify the result.

What Problem Are You Seeing?

Contents

Identify the Direction and the Evidence from That Job

A single district may have several independent integration jobs. A successful demographic import does not prove that contacts, SIRAS exports, or the SIS import also worked.

Direction / processTypical dataPrimary evidence
Aeries → SIRAS Demographics, enrollment, school, grade, identifiers, language, and contacts when enabled. Tools → SIRAS Admin → Scheduled Task Logs; review the current api_import_log.csv.
File-based SIS → SIRAS District demographic and/or contact files. The exact source file delivered for that run plus the applicable SIRAS scheduled-task/import result.
SIRAS → Aeries Special Education student and service information from tableA.csv and tableB.csv. The Aeries Special Ed Data Import completion email and attached reports.
SIRAS → other SIS Special Education, services, and/or 504 data. Presence of the expected SIRAS export file plus the receiving SIS's retrieval/import result.
SFTP connection Secure file/credential exchange and scheduled file retrieval. A manual SFTP connection test, followed by the automated process result.

For an existing student, Student History and the student's Last Import Date may provide additional context. A missing job/log points toward a process or connection issue; a current import date with one unexpected field usually points toward source data, field authority, configuration, or mapping.

Ongoing Monitoring After the Integration Is Live

Once implementation is complete, the primary SIRAS/SPED/SEDS staff should review the evidence produced by each active integration direction on a local cadence that fits enrollment and transfer volume. Weekly is a good default for an active integration. A low-volume district may decide a monthly review is sufficient. Review more often during periods with many new students or transfers, after configuration changes, or while an integration problem is being investigated. Technical staff should remain available for credentials, network, SIS configuration, or scheduled-job problems.

ReviewWhat to look for
Aeries → SIRAS API logUnexpected ERROR or WARNING rows, unexpectedly small populations, or demographic/contact changes that need investigation.
Aeries completion emailConfirm the expected email arrived; review counts and use the Aeries completion-report guide for matched, unmatched, missing-from-file, and service results.
File-based SIS → SIRASExpected source files arrived, processed on schedule, and contained a reasonable record count.
SIRAS → SISCurrent SIRAS files were created/retrieved and the receiving SIS actually completed its import.
Representative student reviewInvestigate high-impact or unexpected changes rather than relying only on job-level success.
“The job ran” is not the same as “the data is correct.”
Review the result counts and actionable reports. The first completion reports during onboarding are also the first monitoring review; continue the same habit after Production activation.

SFTP Connection, Timeout or File-Access Problems

Use SIRAS SFTP: Secure File Exchange & Connection Settings as the canonical connection guide. Before troubleshooting an automated SIS job, prove whether the same district SFTP account can connect manually using the current settings in Article 525.

  1. Confirm the protocol is SFTP.
  2. Confirm the server and port supplied by SIRAS.
  3. Confirm the username and current SFTP password.
  4. Try a manual SFTP connection.
  5. If the client waits, times out, or cannot reach the host before authentication, involve district IT/network staff and review outbound firewall access to .
  6. If manual access works but the automated SIS job does not, compare the automated job's protocol, server, port, username, password, directory, schedule, and network environment with the connection that worked manually.
Verify the result:
Manual SFTP access should work before returning to API credential delivery, file-based imports, or the SIS scheduled retrieval/import configuration.

SIS / Aeries → SIRAS Problems

Confirm the process actually ran

  • Was the API/source file available?
  • Did the scheduled task run at the expected time?
  • Was a current SIRAS log created?
  • Did credentials, URLs, hosting, firewall rules, schools, or schedules recently change?

Confirm the student was present in the exact source

Common reasons a student is absent include a different academic-year database, an excluded school/status, a missing required program indicator, an inactive source record, or a source query/file that did not include the student.

If the student was absent from the source, this is not a SIRAS matching problem.
Correct the SIS, source query, file population, or vendor configuration first.

Aeries: find and filter api_import_log.csv

  1. Go to Tools → SIRAS Admin → Scheduled Task Logs.
  2. Download the current api_import_log.csv.
  3. Open it in Excel or another spreadsheet application.
  4. Filter by Flag, Change Log, Record #, SSID, or Name-DOB.

The beginning of the log can identify enabled preferences such as demographic updates, contact updates, or new-record creation.

FlagHow to use it
INFOIncremental changes applied to records. Sample these rows to confirm that expected values changed.
WARNINGA status or source-data difference that requires review even though the overall job may have completed.
ERRORA record or connection requires correction/manual review, often because identifying information does not match safely.

Aeries: common API log messages

Record already processed — the student may be dually enrolled or represented more than once in the source. Verify which source row was processed and whether the SIRAS result is correct.

SIRAS record is Inactive; update aborted — determine why Aeries still presents the student as active in Special Education and whether the SIRAS → Aeries Special Ed Data Import has delivered the applicable exit/status information.

Active SIRAS record was not present in the Aeries source data — confirm whether the SIRAS record should still be Active, whether the required Aeries Special Education indicator is present, whether the school/status is excluded, and whether the correct academic-year database is being queried.

Aeries: a new record was not created in SIRAS

  • Confirm new-record creation is enabled for the district.
  • Confirm the Aeries record contains the applicable Special Education program/evaluation indicator used by the integration.
  • Review SSID, name, birthdate, Local ID, school, and status.
  • Search SIRAS for an existing transferred, inactive, renamed, or near-duplicate record.
  • If the identifiers are too similar to another record for a safe match, expect an error/review condition rather than an automatic duplicate.
Do not create a second SIRAS student until the import log and existing-record search are complete.

Aeries: contacts are missing or unexpected

  • Confirm contact updates are enabled in the API import configuration/log.
  • Review the Educational Rights Holder information in Aeries.
  • Compare representative students across multiple schools and different family/contact configurations.
  • Use Aeries → SIRAS API Reference: Fields, Defaults & Optional Mapping for the current contact-selection and preference rules.

If an existing district wants to begin automated contact replacement, test that change in Training before enabling it in Production.

Aeries: grade, school or other data looks like the prior year

Confirm the Aeries academic-year database being queried. The Aeries API can use a DatabaseYear value based on the year at the start of the academic year. A prior database year can make grades, schools, statuses, or program indicators look stale.

SIRAS → SIS / Aeries Problems

First separate file creation, file retrieval, and SIS processing

  1. Was the expected SIRAS export file created?
  2. Is the expected file visible in the district SFTP location?
  3. Did the receiving SIS retrieve it?
  4. Did the SIS actually process it?
  5. What completion report, rejected-row report, or error file proves the result?

For general SIRAS export populations, files, and field specifications, use Data Export: Special Education and Section 504 Data from SIRAS to SIS.

Aeries: Special Ed Data Import did not update

  • Confirm the Aeries scheduled Special Ed Data Import is enabled.
  • Confirm Student and Services are included.
  • Confirm the configured file names are tableA.csv and tableB.csv.
  • Confirm the SFTP connection values still match the district account.
  • Confirm the job is scheduled after the current nightly SIRAS files are created.
  • Review the latest Aeries completion email and its attachments.

For the complete SIRAS-specific Aeries configuration recipe, return to Aeries–SIRAS Integration: Configure and Test Both Data Directions. The official Aeries reference is Aeries — Special Ed Data Scheduled or Manual Imports.

Aeries: no completion email

Confirm that the Aeries scheduled/manual Special Ed Data Import actually ran and that the current monitoring contacts are entered as completion-report recipients. The people receiving those reports should be the staff responsible for reviewing daily/regular integration results.

Aeries: Read the Completion Email and Reports

The Aeries completion email is the primary evidence for the SIRAS → Aeries Special Ed Data Import. Review the count and the attached actionable reports rather than treating “the job ran” as the only success criterion.

For the report-by-report interpretation of Match Updated, Type A Unmatched, Type A Unmatched Not in File, and Type B Unmatched, use Aeries Special Ed Data Import: Read the Completion Email & Reports.

Use this troubleshooting page when the result is unexpected. Return here when a student did not match, an exit did not reach Aeries, a file/job did not run, the completion email is missing, or you need to determine which system owns the correction.

Aeries: an older exit did not reach Aeries

An older inactive/exit record may no longer be present in a current SIRAS export, depending on the export population and the timing of the underlying event. Verify the SIRAS record and archive/history first. If the correct historical exit is outside the file population while Aeries still shows the student active in Special Education, Aeries may require a manual correction.

Aeries: a very recent exit did not reach Aeries

If a student was made Inactive and then transferred away or changed program/module before the nightly file was created, verify whether the Inactive record actually appeared in the applicable SIRAS export. Contact SIRAS Support when the file history needs review.

Student Matching, Identifiers & Duplicate Prevention

Depending on the integration, matching can involve SSID, Local Student ID, legal name, birthdate, district/school/site codes, or vendor-specific identifiers.

ResultWhat it usually means
Exact matchThe intended student can be updated.
No matchThe record may be created only when that workflow is approved; otherwise it is logged/reported for review.
Close or ambiguous matchThe integration should avoid making an unsafe update or creating a likely duplicate.
Duplicate source rowsThe SIS/source contains more than one candidate row.
Dual enrollmentOne row may be processed while another is ignored according to the integration's configuration.

Before creating anything new, search for an existing Current, Inactive, transferred, renamed, or near-duplicate SIRAS student.

The Job Ran, but Values Look Wrong

Determine which system owns the field

InformationCommon authority
District enrollment, school, grade, general demographicsUsually the SIS.
Contacts / Educational Rights Holder informationUsually the SIS when automated contact updating is enabled; otherwise the approved local SIRAS workflow.
Special Education participation, meetings, plans, services, disability, program information and exitsUsually SIRAS.
SSID/enrollment information used for CALPADSDistrict enrollment/CALPADS processes; coordinate with SEDS and SIS staff.

Correct the verified authoritative source, rerun the appropriate integration, and confirm the receiving system changes as expected. A manual correction only in the receiving system may be overwritten by the next automated run.

Review mapping only after verifying the source

Common exception areas include grade values, school/site codes, language/EL values, district-specific demographic codes, ignored schools, and multiple program names associated with one physical/CDS site.

Do not assume a mapping problem just because a value is unexpected.
Verify the source value and the normal/default behavior first. For Aeries, use Aeries → SIRAS API Reference: Fields, Defaults & Optional Mapping. Most districts should use standard behavior; document an override only for a confirmed local exception.

Credentials, URLs, Schedules & Other Integration Changes

ChangeWhat to do
SFTP password changesUpdate the approved manual/automated connections that use the account, then retest manually. Use Article 525.
Aeries API credential changesPlace the replacement credential securely in the district SFTP folder and notify SIRAS. Do not email the secret credential.
Aeries base/login URL or hosting changesProvide SIRAS the new non-secret URL and schedule a connection/API test.
Technical or monitoring contacts changeUpdate SIRAS contacts and the SIS/Aeries completion-report recipients.
School/site structure or local codes changeReview any affected mappings/exclusions and test representative records in Training.
Integration preferences changeTest material changes in Training before enabling them in Production.
District changes SIS productContact SIRAS before migration planning/configuration begins.
Do not send passwords, API keys/certificates, or other secret credentials through ordinary email.
Use the district SIRAS SFTP workspace or another secure method approved by SIRAS.

Information to Send SIRAS Support

When the problem remains unresolved, provide enough context to identify the exact job and reproduce the investigation:

  • district / LEA;
  • SIS or vendor;
  • data direction;
  • the specific job, file, or API process;
  • student SIRAS ID and/or SSID rather than unnecessary student-identifying details in unsecured email;
  • date and approximate time of the run;
  • whether the problem affects one student, one school, or many records;
  • exact error/warning text;
  • the applicable SIRAS log, source-file result, SIS completion report, or email;
  • the expected value and where that source value was verified;
  • Last Import Date when relevant; and
  • recent credential, URL, schedule, school, mapping, contact, hosting, or SIS changes.

Email [email protected]. Do not include passwords or API credentials in the support email.

scroll to top icon