Go back to Data Monitoring Help: Investigate a Questionable Record. Missing, unexpected, or inconsistent information is not automatically something to change. Correct only after you understand what actually happened and what the record/report should show.
What Needs to Be Corrected?
| Wrong data in SIRAS Provider corrects ordinary editable data when appropriate, or works with the SPED Clerk when assistance, broader access, or reporting/history review is needed. | Meeting or documents show wrong information Provider works with the SPED Clerk to determine whether the meeting, Current MIS data, or another underlying source must be corrected. |
| Meeting reported the wrong date or reporting information Provider and SPED Clerk review the meeting, Current data, archived transaction, and reporting result before correcting. | MIS Summary validation error or warning Provider corrects ordinary editable data or asks the SPED Clerk for assistance. SPED Clerk handles restricted, historical, or reporting-related issues. |
| SIRAS CALPADS error or warning SPED Clerk investigates and corrects the underlying SIRAS/CALPADS reporting issue before clearing/resending. | Wrong information in CALPADS SPED Clerk reconciles SIRAS, CALPADS, and SIS/SENR when relevant, corrects the upstream source first, then resubmits as needed. |
| Current is right, but SIRAS history is wrong SPED Clerk reviews the archived transaction/history without changing accurate Current data. | SIRAS workflow/status is wrong or incomplete Provider completes the normal workflow when appropriate; work with the SPED Clerk when the meeting/reporting state does not match what actually happened. |
| SIS/SENR enrollment information is wrong or missing SPED Clerk identifies the dependency and coordinates with SIS/enrollment staff when district-controlled enrollment data must be corrected. | The correction is made—what next? Validate, archive/report if needed, submit/resend, verify, and rerun the original monitor. |
- Corrected by Who?
- Provider
- Usually a General User working with assigned students. Providers correct data and complete meeting/workflow tasks that are part of their normal SIRAS access and responsibility. While a newly opened record for a referral allows a Provider to update the MIS, an established plan is locked to the same user on the MIS page. Providers can fix 'wrong' data like an outdated eligibility if provider is part of a triennial event where the eligibility allows them the ability to establish a new eligibility or indicate the current eligibility no longer stands.
- SPED Clerk
- District-level staff who support broader student-data correction, historical/reporting review, SEDS/CALPADS error resolution, and correction paths that providers cannot safely or appropriately complete alone. Have full access to unlock both current and archived data.
- SIS / enrollment staff
- District staff who maintain district-controlled enrollment/demographic source data and SENR reporting when the correction begins outside SIRAS. SEDS reporting to CALPADS is dependent upon accurate enrollment, anything 'wrong' about enrollment will need to be fixed by these staff outside of SIRAS.
Exact permissions and local responsibilities vary. See User Access Roles for SIRAS access context.
Before You Correct
Confirm the correction target before changing data:
- What actually happened?
- What date or reporting period must be correct?
- How old was the student as of the 'effective' or 'report event' date?
- What should SIRAS and/or CALPADS show when the issue is resolved?
- Is the problem in Current data, a meeting, an archived transaction, a SIRAS validation, CALPADS reporting, SIS/SENR, or a workflow state?
- Is this something the provider can correct in the normal workflow, or should the SPED Clerk take over?
If the proposed change would alter a date/event that is already correct, stop and investigate the related workflow, archive, reporting transaction, or enrollment prerequisite instead. Reach out to support instead!
Wrong Data in SIRAS
What do we mean by wrong? It is good to know the context and scope of what could actually be wrong once we identify one wrong element.
| Ex. Situation | Normal path |
|---|---|
| Wrong SPED information in a 30 day | Unlock and fix the MIS Summary page |
| Current plan information on the MIS Summary page | Unlock and fix the MIS Summary page |
| Wrong information accidentally saved into a form | Reopen form and resave, or print backup, delete form, reopen new form and fix. |
| Information resulting from a closed meeting event |
Provider works with SPED clerk to address any errors seen. |
| Archived Transaction Data on the MIS Page resulting in CALPDAS Error |
SPED Clerk investigate the data elements mentioned in the Error Text |
| Caseload for Provider has too many or not enough assignments. |
Provider can use manage caseload to have students removed or added to their caseload. |
| Record is at wrong school or district |
New district can use /tools/request transfer to get record. |
| Meeting form has incorrect contacts |
Fix /student info/student profile/contacts to fix. Adjust SIS if SIS integration is also updating contacts. |
For the Current/archive distinction, see Archived Transactions: Current Data, Components, and Reporting Status.
Meeting or Documents Show Wrong Information
If an IEP/meeting document displays incorrect information, do not treat the document as an isolated word-processing problem. The value may come from the meeting, the student's Current MIS data, or another SIRAS source.
- Provider: identify exactly what is wrong in the document and what the correct information should be.
- Provider + SPED Clerk: determine whether the underlying correction belongs in the meeting, Current MIS data, or another SIRAS location.
- The Meeting documents pull information form the MIS Summary page, so we would look to fixing the MIS Summary page.
- We would want to print a backup copy of the form with the wrong data, delete that form, then reopen a new one to pull in the updated information from the MIS Summary page.
The SIRAS data should represent what actually happened. If the meeting has already been finalized or reported, involve the SPED Clerk before changing the history.
Meeting Reported the Wrong Date or Other Reporting Information
Use this path when the meeting itself may be correct, but the date/outcome/reporting information created from the meeting is wrong—or when CALPADS shows meeting information that does not match what occurred.
Not a Plan Review: do not update Last Annual date, it will NOT get reported that way. Reach out to [email protected]
- Provider and SPED Clerk verify the meeting event type intent, date, outcome, and source documents.
- Staff can have an amendment confirming the team and family's understanding of the intent of the meeting.
- Suggest staff have an amendment documenting the associated meeting intent as a different meeting type
- Correct the SIRAS history without changing accurate Current information unnecessarily.
- Resend the corrected reporting transaction when required and verify the result in CALPADS.
For historical reporting records, see Archive for Reporting: When to Create or Correct an Archived Transaction.
Validate Errors or Warnings on the MIS Summary
SIRAS built-in validations point to missing information, invalid combinations, compliance concerns, and other conditions that should be reviewed before or during normal work.
| Who | What to do |
|---|---|
| Provider | Review the validation. If it points to ordinary editable information within the provider's normal responsibility (program setting, % in Gen. Ed., Degree of Support, and the correct value is known, they can correct if that is the local procedure. If the field is restricted, historical, reporting-related, or unclear, ask the SPED Clerk for assistance. |
| SPED Clerk | If known update to make, SPED clerk and review. Otherwise it may take review of validations that require broader access, administrative/history review, CALPADS context, or correction outside the provider's normal workflow. |
See SIRAS Built-in Validation System for how SIRAS validations work.
If the data accurately represents the verified event, do not invent a correction simply to make the warning disappear.
SIRAS CALPADS Errors and Warnings
When a CALPADS Input Validation Rule (IVR), CALPADS error, or related reporting message appears in SIRAS, the SPED Clerk normally owns the reporting-resolution workflow.
- Read the complete error/warning and identify the affected archived transaction/component.
- Determine whether the underlying problem is SIRAS data, archived history, SIS/SENR, submission order, or CALPADS history.
- Correct the underlying problem first.
- Clear/import/prepare the transaction for resend only as the applicable SIRAS workflow requires.
- Resend and verify that CALPADS accepted the corrected transaction.
Use:
- CALPADS IVR Errors Posted in SIRAS for imported IVRs and the correct-first / clear-second workflow.
- CALPADS Error Summary to look up common CALPADS codes/messages and first checks.
Wrong Information in CALPADS
If CALPADS shows incorrect SPED information, the SPED Clerk should reconcile the posted CALPADS history with SIRAS and, when enrollment is involved, SIS/SENR.
If the bad CALPADS value came from SIRAS or SIS/SENR, correct that source first. Then use the appropriate SIRAS reporting correction/resubmission process so CALPADS receives the verified information.
Possible paths include:
- SIRAS Current and Recent Archive is wrong and both must be corrected before a new/corrected archive is prepared. (current doesn't report to CALPADS)
- A SIRAS archived transaction only is wrong and must be corrected/replaced.
- SIS/SENR enrollment is wrong or missing and must be corrected by enrollment/SIS staff before the SEDS transaction can post correctly.
- A prior or blocking CALPADS transaction (Stay Put Archive, or Archive with older IVR Posted to it) must be addressed before the corrected SIRAS transaction can post.
After correction, use Reporting data to CALPADS and CALPADS Submission Log Help: Verify What SIRAS Sent.
Current Is Correct, but Historical SIRAS Data Is Wrong
Do not change accurate Current data to repair an older reporting problem. An archived transaction is a dated reporting snapshot and can remain wrong even after Current was later corrected.
- SPED Clerk verifies what should have been true for the historical event/date.
- Open and review the applicable archived transaction.
- Correct/replace the historical reporting information using the appropriate archive workflow.
- Resend when required.
- Verify both SIRAS history and CALPADS now represent the event correctly.
See Archived Transactions: Current Data, Components, and Reporting Status and Archive for Reporting: When to Create or Correct an Archived Transaction.
SIRAS Workflow or Status Is Wrong or Incomplete
Sometimes the data is not the main problem. The expected next step may be blocked because a meeting is still open, a reportable event was not finalized/archived, a required workflow step is incomplete, or the record state does not match what actually happened.
| Situation | Normal path |
|---|---|
| Staff in the field inform SPED Clerk meeting can't be closed. | Look to see if Meeting in progress or Pending as of Transaction should be sent. |
| Providers intend to hold hold a 'Plan Review' or 'Triennial' but use the Amendment Meeting Event 'Other Review' | Providers locally document oversight with Director approval. SIRAS staff assist in reporting the corrected meeting date. |
| I know what I am doing but SIRAS won't do what I want! | Escalate to SIRAS with screenshot of the exact screen, workflow state, error/message, and description expected result. |
SIS / SENR Enrollment Information Is Wrong or Missing
Some SEDS/CALPADS errors are caused by enrollment information maintained outside SIRAS. Do not change accurate special education dates just to work around missing or incorrect SENR history. Sometimes it's not SIRAS!
- SPED Clerk identifies the enrollment dependency and verifies what CALPADS/SENR currently shows.
- If district-controlled enrollment information is wrong or missing, coordinate with the appropriate SIS/enrollment staff to correct the source and report SENR as required.
- Verify the corrected enrollment is available in CALPADS.
- Then correct/resend the dependent SIRAS SEDS transaction if needed.
Special Case: Historical Information Cannot Be Obtained
Missing historical information is not automatically an error to invent a value for. First determine what event the missing field is supposed to represent.
- If a new SIRAS record truly must be created for an already-eligible student with an out of State IEP and exact historical referral/initial-entry dates cannot be obtained, use the documented fallback documented in Creating a New Student Record.
Complete the SIRAS Correction Cycle
Once the appropriate person has made the verified correction:
- Recheck SIRAS. Confirm the Current data, meeting, validation, workflow state, or archived transaction now shows the expected result.
- Revalidate. Confirm the original SIRAS validation/error is resolved or now points to the next legitimate dependency.
- Archive or update reporting history when required. A Current correction does not automatically repair a prior archive.
- Submit/resend when required. Use Reporting data to CALPADS.
- Verify the CALPADS job/result. Use CALPADS Submission Log Help: Verify What SIRAS Sent.
- Rerun the original monitor/report. Confirm the original problem is actually resolved and that the correction did not create a new discrepancy.
Continue through the Data Monitoring Journey: Submit when reporting is required, then Verify and return to the original monitor.
When to Stop and Ask for Help
Stop and get assistance when:
- you do not yet know what actually happened;
- the proposed fix requires changing an accurate date/event just to clear a message;
- the provider cannot tell whether the issue belongs in the meeting, Current MIS data, or historical reporting;
- Current and archived history conflict and the correct historical sequence is unclear;
- a CALPADS error appears to depend on SIS/SENR or another LEA's history;
- a required correction is outside the user's permissions;
- the meeting/reporting workflow is correct but SIRAS still prevents the expected action; or
- correcting one value appears likely to require related corrections elsewhere.
Providers should work with their SPED Clerk first when the issue is outside normal provider editing/workflow. SPED Clerks should contact SIRAS Support when the verified correction path remains unclear or SIRAS behavior does not match the expected workflow.
