AzEDS: Answers

F A Q button
Call A D E Support

(602) 542-5154

Contact A D E

Email AzEDS

AzEDS logo


(Click on a question to see the answer)

Will Arizona use AzEDS and Ed-Fi in the 2015-2016 school year?

The short answer: Yes
The long answer: On October 19, 2012, the Arizona Data Governance Commission directed the Arizona Department of Education (ADE) to use Ed-Fi as the Agency’s internal physical data model. The agency has committed to fully implementing AzEDS by July 1, 2015; therefore, all LEAs must be AzEDS compliant by that date to meet the Data Governance Commission’s mandate.

Will SAIS be completely replaced?

Short Answer: Yes
Long Answer: Yes, existing SAIS processing will continue to operate during the transition to the Ed-Fi standard, but as of July 1, 2015, SAIS will no longer be available and all data must be submitted via the AzEDS REST API. Please see the Technical Information for Vendors and LEAs section at for more information.

What is a REST API?
The REST API (application programming interface) is a back-end interface that allows any amount of information to be securely stored and retrieved using the internet. Since REST APIs are always in the back-end, they go unnoticed even though they surround us on a daily basis.

Examples of REST APIs
Facebook, Twitter, Amazon, and online banking: they all use REST APIs to transfer data. Last time you saw a doctor, did they write a paper prescription or send one to the pharmacy in a real-time transaction? The medical field is quickly relying on APIs to communicate information to pharmacies, insurance companies and other doctors. Since all the aforementioned APIs hide behind a web browser, most users are none the wiser.
The AzEDS REST API will work similar to the examples mentioned above. Users will continue to use their SIS to create, modify, delete and search school and student data. Some vendors may have had to reconfigure their SIS to accommodate the new back-end. These changes should be minimal. Vendors will provide any necessary training to their clients to help ensure that the transition to this new behind-the-scenes technology is as smooth and simple as possible.

Although the idea of a REST API may sound intimidating, it really is as simple as checking your email using a web browser.

Recommendations for Data Submission
LEAs are able to configure the schedule for when their data will be submitted (pushed) via the AzEDS REST API. ADE makes the following recommendations regarding schedule and submission configurations:

  • Weekly submission is recommended. Each LEA sets its own submission schedule, which in turn determines what “near real-time” means for them. ADE recommends that LEAs submit data at least weekly and do so daily, if possible.
  • Validate data before submission. In order to reduce submission errors, ADE recommends that LEAs validate data before submitting it. For example, validating that a student is enrolled before that student’s attendance is submitted.

NOTE: ADE does not have insight into the configuration options available in each SIS; LEAs are encouraged to work with their SIS vendors regarding these settings.

Verification and Integrity Reports
ADE expects to run Integrity nightly and provide Integrity reports similar to those currently generated for SAIS. However, verification reports can be accessed through AZDash immediately after each submission to review what data was submitted. Currently ADE is piloting the verification reporting process and expects to have further guidance in May regarding the Integrity report.
ADE is still working on the Aggregation components and have yet to determine the aggregation execution date and time.
The rules for providing discipline will not change. Discipline will continue to be reported via AzSAFE until ADE provides updates on additional applications. The plan is to include Discipline data in the student-data transmission eventually. We do not know when this will occur.
STC Data
STC data will be sent with student data, similar to SAIS transactions. Separate files are no longer necessary. Integrity errors for STC data will be reflected on the Integrity reports so that they can be corrected, just like SPED, ELL, and Student integrity.
Student State ID
As we continue to replace SAIS, applications may be sunset and processes will change. This process will replace the SAIS ID search and generation. LEAs will use this process during the pilot year of AzEDS submissions. The current process of SAIS ID search will continue until June 30, 2015. In FY 2016, existing SAIS IDs will be referred to as Student State ID and will continue to be valid.

How will the Student State ID be different than the SAIS ID?
All State Identities will be stored in a centralized database. Each vendor has programmed their SIS to be able to search and add to this database. Creating this will:

  • Make it easier to find existing IDs
  • Simplify the process of creating new IDs
  • Reduce the amount of duplicate entries
What Will the New Process be for Creating a Student ID?
Each LEA / school will use their SIS to search for new students (using name, gender and birthdate) to see if they have an already-existing identity in the centralized database. The SIS will return any matching, or potentially matching, results. If none of the matches are correct, the SIS will offer an option to create a new identity. A new number will automatically be generated. Once the student is enrolled in the school, the identity is saved in the database.
Staff State ID
Similar to students, teachers will also have a State ID number that is stored in the centralized database. However, unlike students, there are no-preloaded staff ID numbers.

How will the Staff State IDs be Assigned?
Each vendor has programmed their SIS to search the centralized database for existing identities. Before an LEA or school can add a teacher, they must conduct a search (using name, gender and birthdate) to see if an identity already exists. The SIS will return any matching, or potentially matching, results. If none of the matches are correct, the SIS will offer an option to create a new identity. A new 8-digit number will automatically be generated. Once the staff member is added to the school, the identity is saved in the database.
Will this Replace the Stakeholder ID?
The Educator Stakeholder ID is still a separately required ID for Highly-Qualified Teachers. When adding a teacher, this ID can be inputted into the teacher’s data. This ID is independent and cannot be used to search for a Staff State ID.
Do Non-Teaching Staff need a State ID?
At the present time, ADE does not require non-teaching staff members to have state IDs.