Student Preferences

Student Preferences

Preferences let teachers and administrators specify pairs of students who should be placed in the same class. Unlike friend requests (which come from the students themselves), preferences are set by staff based on professional judgment.

What Are Matching Preferences?

A matching preference is a directive to the algorithm: "Try to place these two students in the same class." The algorithm treats preferences as strong hints — it will honor them whenever possible without violating hard constraints like restrictions or capacity limits.

Preferences are bidirectional. If you create a preference pairing Student A with Student B, both students are equally linked — there is no direction to the relationship.

Setting Student Pairs

To create a preference, navigate to the Preferences section from your yearly class dashboard and click "Add Preference." Select the two students who should stay together.

• Each preference links exactly two students.
• You can create multiple preferences for the same student if they need to stay with more than one peer.
• Duplicate preferences (same pair listed twice) are ignored — only one counts.

Conflict Detection

When you add a preference, the system automatically checks for conflicts with your existing restrictions and pre-assignments. Alerts appear inline between the student dropdowns and the submit button — red for errors that block submission, yellow for warnings that let you proceed.

• Match-mismatch overlap (error) — The same student pair already exists in restrictions. You cannot add a preference asking to place together students who must be kept apart. Remove the restriction first if the preference is correct.
• Transitive conflicts (warning) — A chain of preferences contradicts a restriction. For example, if A→B and B→C are preferences but A↔C is a restriction, placing all three becomes impossible. The algorithm will do its best, but at least one constraint will be dropped.
• Pre-assignment conflicts (warning) — Both students are already pre-assigned to different classes, so the preference cannot be fulfilled. You can still add it in case assignments change later.

For a broader view, the Constraint Health card on the class overview page shows a summary of all constraint conflicts across preferences, restrictions, and pre-assignments.

Common Use Cases

• Close friends — A teacher knows two students are inseparable and would struggle socially if placed apart.
• Siblings or relatives — Some schools prefer to keep siblings in the same class for logistical reasons.
• Learning partners — Two students who work exceptionally well together on academic tasks.
• Support relationships — A student who is a positive influence on a peer with behavioral or emotional challenges.
• Parent requests — Sometimes parents ask for their child to be placed with a specific peer. Staff can honor these through preferences.

How Preferences Affect the Algorithm

The algorithm processes constraints in a priority order:

1. Hard constraints first — Restrictions (students who must be separated) and pre-assignments (students locked into a class) are always respected.
2. Preferences next — The algorithm attempts to place paired students together. If a preference conflicts with a hard constraint, the hard constraint wins.
3. Friend requests last — Student-submitted friend requests are optimized after preferences and hard constraints are satisfied.

After generation, the results page shows which preferences were fulfilled and which could not be honored due to conflicting constraints.

Preferences vs. Friend Requests

It's important to understand the difference between these two mechanisms:

• Friend requests are set on individual student records. They represent the student's own wishes (typically gathered from a survey). Each student can request up to three friends.
• Preferences are set by teachers or administrators in a separate section. They represent professional decisions about which students should be together.
• Friend requests are one-directional (Student A requests Student B). Preferences are bidirectional (both students are equally linked).
• Preferences carry more weight in the algorithm than individual friend requests because they represent deliberate staff decisions.

Both mechanisms work together. You can use friend requests for student-driven input and preferences for staff-driven decisions. The algorithm balances both during generation.