Cross-listed sections in Microsoft Teams: one class team instead of five

A cégep teacher gives Introduction to Psychology to four groups. A university professor teaches a course listed under both an undergraduate and a graduate code. In the SIS these are separate sections, each with its own enrollment list, schedule and grade roster. In Microsoft Teams, if each section becomes its own class team, that teacher starts the term with four or five teams for one course.

The problem shows up in week one: the syllabus is posted five times, the first assignment is created five times and questions arrive in five places. It continues all term, because every announcement, file and grade has to be repeated, and it ends with five teams to archive instead of one.

Why does every section become its own team?

The SIS treats the section as the unit of everything administrative: enrollment, scheduling, teaching load and final grades. Sync tools follow that model, so one section record becomes one class team. As a default, that is sensible.

Cross-listing is a relationship between sections, and each SIS records it in its own way. Banner works with cross-list groups, PeopleSoft Campus Solutions with combined sections, and in Quebec cégeps the same course is routinely split into several groups taught by one teacher. Unless the sync tool reads that relationship, it has no way to know that five sections should share one team.

Microsoft Teams itself offers no feature for merging two existing teams. Once five teams exist and students are working in them, consolidating means moving content and people by hand.

The structure also changes after teams exist. A section opens late because demand was higher than planned, or a low-enrollment section is folded into another, and the team model has to absorb the change without a rebuild.

What does one team per section cost?

The cost lands on several groups at once.

The cost grows with the number of multi-section courses. A department that offers core courses in many groups can generate a steady stream of merge requests at the start of each term, each one a manual task for someone, often during the busiest weeks of the year.

There is also a quality cost. Teachers who maintain five copies of the same course drift: a correction made in one team is forgotten in another, and students in different sections end up with different instructions. Five Class Notebooks also mean five Content Libraries to fill and five sets of student sections to check.

What doesn't work

Most improvised merges fail in the same way: they work on day one and drift by week two.

• The teacher builds a master team. Students are added by hand or with a join code. The team drifts from the SIS as soon as add/drop starts, nobody is ever removed, and the official section teams still exist alongside it.
• Merging rows in the import file. Combining sections into one class before the sync produces one team, but the team no longer records which student belongs to which section, and the merge has to be redone every time an enrollment changes.
• Reusing one section's team. Adding the other sections' students to section 01's team works for a week. After that, every change in sections 02 to 05 has to be copied by hand.
• Merging after the fact. Once teams are in use, merging means moving files, recreating assignments and asking students to switch teams. It is slow and loses history.

How to merge sections into one class team

The goal is one team where teaching is shared, without losing what the SIS knows about each section. Start by deciding which courses should merge at all.

Then apply these steps.

1. Define merge rules from SIS data

Base merges on data the SIS already holds, such as a cross-list group, a combined section or an explicit list of section IDs, rather than on emailed requests. A rule stored this way can be reproduced next term without anyone having to remember it.

2. Decide merges before teams are created

Merging is cheap before the first sync and expensive after it. Collect merge rules before term start, ideally from departments or the scheduling office, and treat late requests as exceptions. When a section opens late because demand was higher than expected, attach it to the existing merged team instead of creating a new one.

3. Name the merged team so it can be traced

Give the merged team a name that students recognize and administrators can trace back to its sections, for example F2026 · PSY-101 · Introduction to Psychology (01–04). Students in every section should find the same course title they saw at registration.

4. Keep section identity inside the merged team

Students from all sections share the General channel, but a channel per section keeps section-specific discussions and announcements apart. Keep track of each student's section for reporting: the SIS remains the gradebook of record per section. The day-to-day workflow inside a class team is described on the Teams classroom page.

5. Use one Class Notebook

A merged team means one Class Notebook: a Content Library the teacher maintains once, a Collaboration Space, and a private section for each student that only the student and the teachers can see. That private section is what keeps individual work separate across sections.

6. Keep enrollments flowing from every section

A drop in section 03 or a late add in section 05 must update the merged team. The sync has to treat the merged team as the target for all of its source sections, with the same cadence as any other team; the mechanics are covered in add/drop week without tickets.

7. Archive the merged team like any other

At the end of term, the merged team follows the same archive policy as single-section teams. One team to archive instead of five is a small but real gain.

Merging does mean that students see classmates from other sections in the member list. For most courses that is acceptable, but check your institution's policy for sensitive programs, and use per-section channels wherever discussions should stay within a section.

How Teameo handles cross-listed sections

Teameo calls this meta-course fusion. Cross-listed or multi-section courses are merged into one class team with a shared General channel and a single Class Notebook, and channels per section can keep each group's discussions apart.

Merge rules are configured per course from SIS data, so the department decides how a course is taught in Teams and IT does not have to adjudicate every request. Enrollment changes from every source section keep flowing into the merged team in real time or on a schedule, and a student added late gets a Class Notebook section at the same time.

Every merge, enrollment change and end-of-term archive is logged with a timestamp and its actor, which helps the registrar's office reconcile the merged team with official section rosters. Teameo applies merges to the SIS platforms it supports, from Omnivox, Clara and COBA to Banner, PeopleSoft Campus Solutions, Workday Student and Jenzabar; the overall setup is explained in how to sync your SIS with Microsoft Teams, and the full product on the Microsoft Teams for Education page.