This article owns the implementation process. Detailed inbound field structures are documented in Articles 50 and 9. SIRAS outbound file layouts and field specifications are documented in Article 69.
1. Confirm SFTP Access
Before working on automated SIS jobs, confirm that the district can connect manually to its SIRAS SFTP location. Use SIRAS SFTP: Secure File Exchange & Connection Settings for the host, port, username, password, manual connection test, and firewall troubleshooting.
A district or SIS technical contact can connect manually to the district SFTP location.
2. Identify the Student Population in the SIS
The SIS needs a way to identify the students whose data should be sent to SIRAS. Some SIS products may still support the legacy Special Education Program 144 indicator or another local Special Education flag.
If the SIS does not already maintain a reliable current Special Education population, the district may use SIRAS studentData.csv to help seed or reconcile it. When using that file to identify current active Special Education students, Inactive Reason must be blank.
See Data Export: Special Education and Section 504 Data from SIRAS to SIS for the outbound file structure.
3. Send the First File(s)
The first goal is to get a representative demographic file into the district SFTP folder. A manually generated file is appropriate for initial testing. Contacts can be tested at the same time or added later.
| Inbound file | Suggested filename | Use |
|---|---|---|
| Special Education demographics | {7-digit district CDS code}_demographics.csv | Primary inbound file. |
| Special Education contacts | {7-digit district CDS code}_contacts.csv | Optional parallel contact exchange. |
| Section 504 demographics | {7-digit district CDS code}_504demographics.csv | Optional when the district wants SIS 504 demographics to update SIRAS. |
| Section 504 contacts | {7-digit district CDS code}_504contacts.csv | Optional when the district also wants to send 504 contacts to SIRAS. |
| Accepted formats | CSV, XLS, or XLSX. |
| Date formats | YYYYMMDD or DD/MM/YYYY. |
| Column order | Not important; descriptive headers are required. |
| Location | District home location on the SIRAS SFTP. |
| Suggested automated delivery window | 12:00 a.m.–1:00 a.m. local time. |
Use Data Import: Demographic File Specification and Data Import: Contact File Specification for detailed inbound field structures.
SIRAS has received representative file(s) and can begin reviewing their structure and source values.
4. Review the File and Results in Training
- SIRAS reviews the headers, identifiers, source values, schools/programs, dates, and other incoming data.
- SIRAS configures the initial file interpretation and processes the file in Training.
- Local SPED/SEDS staff review representative students and the applicable processing logs/results.
- The district and SIRAS identify any source-data or mapping changes that are actually needed.
- Retest until the Training results reflect the intended behavior.
Start with the standard integration behavior. If Training reveals a real local difference—for example, Kindergarten appearing as Infant or 12+, a local code with a different meaning, or multiple school/program names sharing one physical/CDS site but needing distinct names in SIRAS—tell SIRAS what result is unexpected. SIRAS can review the actual incoming value and confirm whether a local mapping is needed.
District SPED/SEDS staff confirm that representative Training results are correct.
5. Enable the Approved File Processing in Production
After the district confirms the Training results, SIRAS can enable the approved file processing in Production. Continue reviewing the first Production runs closely so source-file, matching, or mapping issues are found before they become routine.
6. Work Toward Nightly Automated Delivery
Manual file delivery is fine for initial testing and can be used temporarily while technical automation is being completed. The longer-term target is for the SIS to automatically generate and post the current demographic file—and contact file when used—each night.
Coordinate any district- or vendor-specific timing differences with SIRAS.
Some districts do not have dedicated technical staff onsite. SIS vendor support, county office staff, or other district technical resources may be needed to automate the export. It is fine to continue with a documented manual process while that work is underway.
7. Complete the SIRAS → SIS Side
The file-based implementation should also address how SIRAS information gets back to the SIS. Full bidirectional automation is the target, but districts can use the best automated or manual process their SIS supports.
- Special Education: use
studentData.csvwhere the SIS can consume or reconcile it.serviceData.csvis also available for local use but is not a primary SIS-integration target. - Section 504: districts using the SIRAS 504 module need a dependable process for getting new 504 participation and 504 exits back to the SIS. Automated use of
504StudentData.csvis preferred when supported; otherwise define a manual handoff.
The SIS is responsible for the district's Section 504 reporting to CALPADS, including the applicable Program 101 workflow. A new 504 determination or 504 exit in SIRAS cannot remain isolated in SIRAS.
For all SIRAS-generated SIS-facing files, populations, field layouts, legacy headers, and file-update behavior, use Data Export: Special Education and Section 504 Data from SIRAS to SIS.
Service information is also available through Service Export, and SIRAS service logs can support the MediCal billing workflow described in MediCal Billing in SIRAS.
8. Monitor the Exchange After Go-Live
Assign staff to review the applicable SIRAS processing logs and receiving-SIS completion evidence weekly or more often when appropriate. A file appearing in SFTP does not by itself confirm that the receiving system processed it successfully.
Use SIS Integration Troubleshooting & Ongoing Monitoring for missing files, matching problems, unexpected values, credentials, schedules, and other established-integration issues.
