Student Preferences

Student Preferences

Preferences let teachers and administrators specify pairs of students who should be placed in the same classroom. 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 classroom." 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 placement workspace and click Add Preference. You need at least two students in the roster before this section becomes editable; if the roster is too small, Shibutz points you back to Students first. 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 required placements. 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. Delete 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.
• Required placement conflicts (warning) — Both students are already required to be in different classrooms, so the preference cannot be fulfilled. You can still add it in case placement requirements change later.

For a broader view, the Constraint Health card on the workspace overview shows a summary of all constraint conflicts across preferences, restrictions, and required placements.

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 classroom 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 required placements (students locked into a classroom) 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.