Set Staff Pairing Preferences

Preferences let teachers and administrators specify pairs of students who should be placed in the same classroom. Unlike friend requests (recorded by staff from student input), preferences are separate staff-set pairs. They do not populate the friend lists on student records.

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.
• Adding a pair already listed shows Pair already listed. Reversing the two students still counts as the same pair.

Wait for the saved confirmation before relying on a new preference. If saving fails, your two student selections stay in the form so you can try again without reselecting them.

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 together becomes impossible. At least one pairing preference cannot be fulfilled; the restriction remains a required separation.
• 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

Keep these different types of input separate:

1. Hard constraints first — Restrictions (students who must be separated) and required placements (students locked into a classroom) are always respected.
2. Staff Preferences — The engine attempts to place paired students together. If a preference conflicts with a hard constraint, the hard constraint wins.
3. Student friend requests — Up to three directional requests on each student's record are sent separately from staff pairs. They are not guaranteed placements.

After generation, the results page shows student friend outcomes. Those percentages do not measure staff Preferences. Check the generated classrooms for the staff pairs you need to review.

Preferences vs. Friend Requests

Use the field that matches the input you are recording:

• 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).
• The interface does not expose numerical weights for either input. Use Required Placements for a required destination classroom, rather than assuming a preference guarantees it.

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.