Sharebar?

OneRoster Implementation FAQ

planning icon

Planning

Actionable steps for successful implementation

data governance icon

Data Governance

Elements of Strategy 
and Execution

implementation icon

Implementation

Processes that ensure
strategic goals are met

user roles icon

User Roles

Effective use
of permissioning

 


 Useful Links

 
 
 
 
 
 


QUESTIONS

 

Planning

 

Data Governance

 
 
 
 
 

Implementation

 
 
 
 

User Roles

 
 
 

ANSWERS

 

planning icon Planning

What if my vendor is reluctant to adopt OneRoster?

The path of least resistance is to include the demand for OneRoster in your procurement language. 1EdTech offers sample RFP language that can be helpful. Setting a timeline for making the transition is also helpful—require that a vendor is able to support OneRoster by the time a contract renewal takes place. If that does not take place, it may be necessary to choose a new vendor. The 1EdTech Certified Product Directory is a useful resource for finding products that have achieved 1EdTech conformance certification.

What if a vendor is reluctant to adopt the API solution? My vendor supports the .csv but not the API.

It is always important to work with vendors in advance. It is suggested that your requirements are written into your procurement language. Let your vendors know that they must support the 1EdTech initiatives that align with your strategic goals. Anytime you are adopting an API solution, be sure to involve your instructional team and help them understand the benefits.

 Data Governance

How do I manage data that is used in different ways? Example: enrollment date for a district is the beginning of the school year but for a publisher, it is the first time the student accessed their system.

The best practice is to create a data mapping between data fields required by the vendor with those in your SIS and then request that the vendor make a correction before going live.
 

What do I do if my files need to go through a validation process?

1EdTech recommends districts consider four levels of validation testing. The highest level of testing would be verifying data transferred from the provider to the consumer without failure. The next level is to do a high-level record count; i.e., a certain number of records transmitted from the provider and the same number of records are received by the consumer. The third level of validation is a detailed level check to ensure data is mapping to the correct fields upon import. The last level of validation is an action level check where executing processes on the consumer system creates the expected results.
 

What do I do when my vendor wants to use their own naming conventions and codes?

Vendors must accept the school districts’ naming conventions. A suggested best practice is to create a data dictionary and district nomenclature and share it with vendors during the procurement process.
 

How does my district maintain the same course or class title across multiple vendors?

In order to avoid problems, providing examples of data for every field to be used early in the adoption process is recommended. It may be necessary for some vendors to modify their product.
 

How do we convince parents to share student information across vendors?

It is important to share information with parents about privacy and how the benefits compare to other solutions. Ensure your parents that by using API, you are only sharing information you need to share.
 

How do I avoid vendors using middleware tools? Vendors prefer to use middleware tools that use OneRoster with a school's SIS to keep their proprietary ways in the backend.

To avoid middleware tools, it is important to adopt OneRoster certified products whenever possible. When vendors you currently work with don’t use OneRoster compliant products, engage in conversations with them about your wishes and possible future requirements to help; encourage them to utilize products which meet the OneRoster standard.

 Implementation

Why is my vendor requesting information they do not need?

Both vendors and the district/institution will benefit from proper data management. Communicate the scope of the project early with the vendor and be specific about the data that is necessary for the implementation. Doing this first can alleviate unnecessary work and/or exchange of extraneous data in the future. Be clear with vendors what data will be shared with them. For example, you may want to share only the data pertaining to students who are using a particular tool, app, or platform. You don’t want to share an entire SIS data structure. Take advantage of the API if that is available. And reach out to 1EdTech if you have questions; we can help connect you with other 1EdTech members to learn about their data management strategies. 

 

How can I make sure my expectations are met with each vendor? Certified vendors promised features they cannot deliver and are part of the specification. 

Contact 1EdTech when a vendor is not meeting established expectations.
 

How do I avoid vendors using middleware tools? Vendors prefer to use middleware tools that use OneRoster with a school's SIS to keep their proprietary ways in the backend.

To avoid middleware tools it is important to adopt OneRoster compliant products whenever possible. When vendors you currently work with don’t use OneRoster compliant products, engage in conversations with them about your wishes and possible future requirements to help encourage them to utilize products which meet the OneRoster standard.
 

How can I avoid glitches and errors now that my integration is live?

There are a few things you can do to avoid glitches and errors once an integration is live. Before implementing, ask vendors about their experience with previous deployments to get an idea of potential obstacles in your own integration. Test your integration first in a sandbox or test environment. You can also request that vendors work in testing environments instead of production sites, to begin with. 
Note: All implementations will experience errors at some point. It is important to have an error handling strategy for when that occurs.
 

Why is the vendor not excluding records where the To-be-deleted flag has been set?

To fix this issue when a CSV format is used, filter the data before it is transmitted.

 User Roles

What if my course has a secondary teacher? Most vendors don’t support that string. 

If the vendor supports secondary teachers and you are using OneRoster 1.0 considered moving to OneRoster 1.1. If the vendor does not support secondary teachers, work with the vendors to find a solution. At a minimum, you should try to get the vendor to consider supporting secondary teachers in a future release.
 

What happens when a teacher has multiple roles?

If the vendor does not support multiple roles you will need to work with the vendor to provide a solution. As a workaround, you may have to assign the role based on the most important functionality of the product. For example, if the Teacher Role is required in order to provide the most important functionality then the teacher should have the teacher role. If the Administrative role provides the teacher functionality in addition to the administrator function then the teacher should have the administrator role.
 

Is it possible to have multiple administrative role types?

To create multiple administrative role types, add a metadata column in Users.csv to identify specific role types. You can alternatively add a dummy class in the Enrollments.csv file to identify administrators. In the worst case, you may need to manually maintain the additional roles in the software.
 

Is it possible for a user to be associated with multiple locations/schools?

Having a user be associated with multiple schools depends on the vendor’s capabilities. If the vendor supports multiple locations then you can have multiple rows in the data (one for each location). If the vendor does not support multiple locations you will need to work with the specific vendor to provide a solution.