Planning Checklist For School Data Sync (SDS)
We're excited to announce that the new School Data Sync (SDS) experience is in Public Preview. The new SDS experience is an opt-in during our Public Preview.
During Public Preview we do not recommend environments, with more than 50k users, where provisioning tasks (writing users, groups, and memberships to Azure Active Directory) may take more than 24 hours to process.
During Public Preview we do not recommend environments that need to directly connect data from multiple SISs into a single subscription. If this configuration is needed then pre-processing, outside of SDS, will need to occur to combine the data before submitting the data through one of the supported CSV formats. Username values in the CSV will need to include the fully qualified domain value, e.g. username@domain, for user targeted-domain identity mapping.
To effectively plan an SDS deployment, there are some important details regarding data format for synchronization, user identity rules and matching you should be aware of. These concepts and recommendations are referenced often, as they have broad impact on planning decisions. Before you can effectively plan your deployment, you must understand core SDS concepts.
Planning an SDS deployment isn't overly complex. Below are a few key options and configuration items that need to be considered when deciding how to configure SDS for your environment.
School Data Sync Requirements
- Microsoft 365 Education tenant
- Need Global Administrator Permissions
Considerations when configuring SDS
Comparison of deployment methods
|Advantages||Control over data to be synched||Automated process (sync/ update)|
|Full autonomy from third parties||Same standardized data in local SIS/SMS and in SDS|
|Disadvantages||Little automation possible||No manual intervention possible to correct/amend data|
|Room for human error||Dependence on third-party API providers, their data quality, and their performance|
|Action required whenever there's a change/update in data|
|Best fit for||Small organizations (<= 10,000 users)||Organizations with one SIS/SMS compatible with OneRoster API.|
|Organizations with multiple SIS/SMS student databases (must be premerged before uploading to SDS)|
*Organizations interested in setting up an API connection to their own SIS should use OneRoster API - Onboarding Guidance for OneRoster API Providers with SDS. The article includes steps needed to request being added as a OneRoster provider, including testing and validation.
What is your data source?
If you have a OneRoster 1.1 capable Student Information System (SIS)/ Student Management System (SMS), you may sync via API. But if your SIS/SMS isn't OneRoster V1.1 capable, you need to upload your data with the SDS v2.1 CSV format.
Have you prepped your data source for sync (created CSVs or set up for API config)?
API configurations require you to complete certain steps within the SIS/SMS, as detailed on the API sync providers' pages.
CSV deployment requires exporting data from your SIS/SMS. You may also have to adjust the export from your SIS/SMS, as comma-separated files and UTF-8. See SDS v2.1 CSV file format.
Are you creating new users or syncing existing users?
If you already have users in Microsoft Azure Active Directory (Azure AD), and you don’t need to create initial accounts, then you don't need to choose the option to "Create unmatched users" as part of the "Manage users" configuration. If you have a brand new Microsoft 365 tenant without any users currently present and you don’t plan to sync user accounts from an on-premises active directory, you may choose the option to "Create unmatched users."
If you have a combination of existing users and need to create new users, you only need one "Manage users" flow. Enable the option to "Create unmatched users".
If creating new users, what licenses will be applied to those users?
If you select the "Create unmatched users" option, you can choose to assign a license to each student, and staff account created. Review the available licenses within your tenant to assign the appropriate option for students and staff. For more information on completing a custom license application across your users, see License Microsoft 365 Users via PowerShell.
If syncing existing users, how will you match identities for students and staff?
Identity matching is one of the most common issues encountered while deploying SDS. Planning your User identity rules and matching strategy is critical to creating and enabling sync with your source data. For how to configure identity, see User Identity Rules.
Take time to understand how your SIS/SMS user data looks and review User Identity Rules to devise the best strategy.
If syncing existing users, are all student and staff accounts already created in Office 365?
When they're created, you’re ready to prep your CSV files, or API-connected source directory and begin syncing.
If all users haven't been synced from your on-premises active directory or created as cloud-only identities, first complete those steps, or use SDS to create cloud-only identities within your tenant.
If your tenant is going to be syncing from your on-premises active directory, you should NOT ENABLE the option to 'Create unmatched users'. User records that don't find a match will be matched during the next run if those users have been synced from your on-premises to your tenants' active directory.
If you're not going to be syncing users from your on-premises active directory, then you should configure to 'Create unmatched users' as cloud-only identities.
Which values do you want to sync to Azure AD, and when?
When configuring your Microsoft 365 Users or Microsoft 365 Groups and Teams, choose the attributes for users and group properties for your groups that you want to sync. There are two types: required and optional. Required attributes can't be unselected.
Will you allow your teachers to overwrite group’s DisplayName after they are initially synced/created by SDS?
When SDS syncs a section, it creates a Microsoft 365 group. A default behavior of a Microsoft 365 group is that the owner may overwrite the DisplayName after the group is created. While SDS doesn’t change this capability, you can configure SDS to reset the DisplayName to the original, and intended value each time sync is run. If you want to allow teachers to manage and maintain the DisplayName after the initial sync, you should leave the option selected when configuring Microsoft 365 groups and Teams set up.
Do you want to delay student access to Class Teams?
For Microsoft 365 groups and Teams configuration, SDS creates Microsoft 365 groups synced for each section. The selected student and staff roles become members, based on the SIS/SMS rostering section enrollment data being synced. Once the group and memberships are fully populated, the students are able to see which groups they're a member of via Outlook Web Access and OneDrive. They'll also be able to see owners of their sections.
If you wish to delay exposing this information to students, you may delay the student enrollment processing by NOT selecting the student role for the group memberships when going through the configuration, or edit to remove before starting the academic year transition.
- When ready, you can edit your Microsoft 365 groups and Teams flow configuration and select the student role. On the next run, the changes will process and add the students to their groups.
If you simply wish to delay Class Teams access to students instruct educators on the following:
- Toggle is on:
- For Educators, or group owners that are using the created Class Teams from SDS they have early access before the students and other group members. When the educator is ready, they can select Activate to allow students and other group members access.
- Toggle is off:
Do you need to sync more than one time?
If you're syncing via API, an automated run occurs every 12 hours.
If you're syncing via CSV file, a run occurs upon the initial upload and then again when new CSV files are manually uploaded. An automated run every 12 hours will still occur to process Azure AD changes.