Beyond School Data Sync basics

  • 12 minutes

This section covers advanced and optional School Data Sync (SDS) scenarios intended for experienced IT administrators. Some steps require PowerShell access or advanced Microsoft Entra ID configuration.

In this unit, we dive a little deeper and explore some common SDS customization options to tailor your installation to your organization's needs, including:

  • Managing custom List of Values
  • Resetting Managed data provisioning types
  • Planning for multiple domains in a single tenant
  • Using PowerShell to hide SDS class groups from the global address lists (GAL) and Exchange clients
  • Creating conditional access policies based on your SDS security groups
  • Giving staff the ability to reset student passwords using SDS administrative units

Use List of Values (enums) to validate data

To support better data validation and normalization, SDS includes List of Values (also called enums). Enums are used throughout SDS to validate incoming SIS data against expected values. SDS includes default List of Values, and you can extend these definitions to support regional or organizational needs.

Custom List of Values should be planned carefully, as changes affect all inbound data validation and can introduce errors or warnings across future sync runs if SIS values aren't aligned.

Customizable List of Values types include:

  • Academic subjects
  • Demographic ethnicity
  • Demographic race
  • Grade level
  • Organization types
  • Person flags

During data processing, SDS validates incoming data using these codes. Only valid required or optional data is written to the SDS cache. Invalid values trigger errors or warnings and are excluded.

Matching is case-insensitive and normalized to the stored List of Values code. If an unrecognized code is provided, SDS raises an error or warning in Sync Health.

For the full documentation, refer to aka.ms/ManageSDSEnums.

Review and manage List of Values

To review default values and manage tenant-specific values:

  1. In the left navigation menu, select Settings.
  2. Select List of Values.
  3. Expand a value type to review codes and descriptions.
  4. Add new values or manage existing ones as needed.

The full default list is available in SDS documentation or at aka.ms/ManageSDSEnums.

Add a new grade level using List of Values

To add a new grade level:

  1. Select Add to List of Values.
  2. Select Grade level as the value type.
  3. Enter a unique reference code (for example, 15). This is the value that SIS data uses during import.
  4. Enter a user-friendly Display name (for example, "Grade 15"). Display names must be 255 characters or fewer.
  5. Select Add to submit.

If you're successful, SDS displays a message that the grade level was added successfully. You can add more values or disable a value if it should no longer be used.

  • Disabling a code prevents new associations from being accepted.
  • Existing records remain linked.
  • Disabled values can be reenabled at any time.

Reset a Managed Data provisioning type

Reset clears the internal delta file SDS uses to compare the SDS cache with Microsoft Entra ID. It does not delete provisioned objects. Instead, it forces SDS to fully reprocess all active data during the next sync run.

Note

Reset runs take longer than normal sync runs because SDS compares each record line by line.

Warning

Reset operations should be used sparingly and only after validating SIS source data. Because resets trigger full reprocessing, they can significantly increase sync duration and impact downstream provisioning.

Two common scenarios for needing a reset include:

  • Scenario 1: Errors persist even after fixing SIS data - You removed unused classes (like lunch or study hall) from the SIS or CSV, but SDS still reports errors. SDS might be comparing against outdated delta information. Resetting the Class groups provision type forces SDS to reprocess the current data and resolve outdated errors.
  • Scenario 2: A class was unintentionally deleted - A teacher accidentally deleted an active class in Teams due to class names from different years being similar. Resetting Class groups reprocesses the active SIS data and recreates the class with correct membership.

Note

Reset doesn't restore the deleted Team—it recreates the group and memberships based on SIS data.

To reset a data provisioning type:

  1. Go to Sync configuration.
  2. Select Manage Data.
  3. Locate the provisioning type (for example, Class groups).
  4. Select Reset.
  5. Select Confirm.

Warning

Reset requests can't be stopped or undone.

SDS will reprocess all active data on the next sync run.

Multiple domains in a single tenant

When staff and students use different domains, you can append a domain suffix in the user identity rules. However, do not append domains if:

  • The tenant has multiple staff domains, or
  • The tenant has multiple student domains.

In these scenarios, the domain suffix must be present in the SIS data. SDS can't dynamically pick from multiple domain options when matching against User Principal Name (UPN) or Mail attributes.

Hide class groups from the GAL and Exchange

Class groups appear in Exchange Online as unified groups. Some institutions prefer to hide these groups from:

  • The Global Address List (GAL)
  • Exchange clients, like Outlook and Outlook on the web

PowerShell commands are available to:

  • Hide a single class group
  • Hide all SDScreated class groups
  • Hide from the GAL
  • Hide from Exchange clients

Note

This scenario requires familiarity with Exchange Online PowerShell. Organizations should test scripts in a pilot environment before applying them broadly.

For instructions and scripts, visit aka.ms/PowerShellForSDS.

In multi domain environments, identity values should be fully qualified in the SIS to avoid ambiguous matching and downstream provisioning failures.

Use SDS security groups with conditional access

SDScreated security groups can be used to create conditional access policies. These policies define which applications or resources users can access and under what conditions.

Examples of conditional access use:

  • Restrict primary students from accessing secondary level apps
  • Apply different policies for staff and students
  • Limit app usage by school or region

Security group assignments update automatically when SDS updates user roles and school associations.

Conditional Access policies can block user access if misconfigured. Always test new policies in a report only or limited scope configuration before enforcing them tenant wide.

Create a conditional access policy to block students from using non-Microsoft applications

To create a policy that prevents students from signing in to third-party (non-Microsoft) applications, you must enable the Security groups provisioning type with the Role groups option selected. SDS then creates two groups:

  • Students: Includes all users whose Microsoft Entra ID user object has a primary role of Student
  • Staff: Includes all users whose Microsoft Entra ID user object has any primary staff role

As SIS data changes, SDS automatically updates the group memberships in Microsoft Entra ID.

To create the conditional access policy:

  1. In the Microsoft Entra admin center, open the Conditional access policy editor: aka.ms/SDSHGatingCAPolicyEditor
  2. Select New and name the policy "Block student access to non-Microsoft applications".
  3. Under Assignments > Users and groups:
    • Select Users and groups.
    • Select the Students security group.
  4. Under Assignments > Cloud apps, select:
    • Include > All cloud apps
    • Exclude > Microsoft applications
  5. Under Access controls:
    • Switch from Grant access to Block access.
    • Turn the control ON.
  6. Select Create.

To allow certain third-party apps:

  1. Go to Assignments > Cloud apps > Exclude.
  2. Select the applications you want students to access.

Use SDS administrative units for role-based access

You can use SDScreated and managed Administrative Units (AUs) to support delegated administration. This access lets authorized teachers or staff manage only the users and classes at their assigned school and perform student password resets.

To enable role-based access:

  1. Enable the Administrative units provisioning type using the Organizations + role groups option. This creates two AUs per school:
    • SchoolName + Students: Contains all student users associated with that school
    • SchoolName + Staff: Contains all staff users associated with that school
  2. After enabling this option.
  3. Wait for the next sync run to complete.
  4. Go to People, search for the staff member, and enable the Password administration role.
    • This gives the staff member permission to reset passwords for students in the same organization.
    • There might be a short delay before the new role is fully active.

For help configuring delegated password resets, visit aka.ms/SDSDelegatedPasswordReset.