One source of truth: connecting your SIS to Teams, Moodle and calendars

Every college and university already has a system that knows exactly which students are enrolled in which sections, who teaches them, and when and where they meet. It's the student information system (SIS): Omnivox, Clara or COBA in many Quebec cégeps, Banner, PeopleSoft Campus Solutions, Workday Student or Jenzabar in many universities. The trouble is that students and faculty don't spend their day in the SIS. They live in Microsoft Teams, Moodle, Outlook and Google Calendar.

So the same information gets copied into three or four places, by different people, on different schedules. It looks fine during planning. It breaks during add/drop week, when a student who registered late can't find the class in Teams, a section moves rooms and the calendar still shows the old one, or a cross-listed course shows up as three separate Moodle courses.

Why do Teams, Moodle and calendars drift away from the SIS?

Because each platform usually arrived on campus with its own integration. Moodle got a SQL script and a cron job when it was installed. Teams got a CSV export when remote teaching started. Calendars got an ICS feed, or nothing at all. Each connection was reasonable on its own. Together they form a set of point-to-point copies that nobody owns end to end.

Three things make the drift worse:

• Different owners. The registrar's office owns the SIS, the Microsoft 365 administrator owns Teams, the Moodle administrator owns Moodle. Nobody owns the rules between them.
• Different interpretations. One script merges cross-listed sections, another doesn't. One matches accounts on the SIS student number, another on an email address that changed last year.
• Platforms that keep moving. Microsoft and Moodle ship updates continuously. Every change to an API, a team template or a Moodle version is one more chance for a home-grown script to fail quietly.

What it costs

The visible cost is IT time. Maintaining provisioning scripts, fixing enrollment mismatches and archiving classes at the end of term typically takes an IT team 40 to 80 hours per term, depending on the size of the institution and how much is already automated. Our methodology page breaks down a 42-hour estimate for a mid-sized college, task by task.

The less visible costs land on people:

• Students who register late miss a first class or a first assignment because the course isn't in Teams or Moodle yet.
• Faculty build their own class spaces by hand "just in case", which creates duplicates, inconsistent names and orphaned teams that nobody archives.
• The help desk spends the first two weeks of every term on access tickets.
• When a privacy officer asks who added a student to a class and when, the answer is spread across several logs, or doesn't exist.

What doesn't work

Letting each platform fend for itself. Asking faculty to create their own Teams or Moodle courses gives them control, but it disconnects the class from the roster. Someone still has to add and remove students, and the institution loses any consistent naming or archive policy.

Nightly exports. A CSV file that runs once a night is better than nothing, but it creates a day of lag at the moment when changes are most frequent. It also tends to add students without ever removing them.

One script per platform. Custom scripts work until the person who wrote them leaves, the SIS is upgraded, or the platform changes its API. Every new platform multiplies the maintenance.

Expecting a K-12 tool to cover higher education. Microsoft School Data Sync is a solid, free option that many school boards rely on. It wasn't designed around higher-education needs such as cross-listed sections merged into one class, several instructor roles or term-based archive policies. Evaluate it against your own scenarios rather than assuming either way.

How to make the SIS the single source of truth

The goal isn't to buy one more tool. It's to agree on a few rules and apply them to every platform the same way.

1. Edit class data in one place. Sections, enrollments, instructors, schedules and rooms are created and changed in the SIS. If a roster is wrong in Teams, the fix happens in the SIS.
2. Flow in one direction. Data moves from the SIS to the platforms. Define the rare exceptions explicitly (a guest lecturer, a teaching assistant added by a department) instead of allowing silent edits.
3. Use stable identifiers. Match each SIS section to one team, one Moodle course and one calendar series, and each student number to one Microsoft Entra ID account. Names and email addresses change; identifiers shouldn't.
4. Write the rules once. The naming convention, the fusion of cross-listed sections, instructor and co-instructor roles, and the end-of-term archive policy should be the same for Teams, Moodle and calendars.
5. Propagate changes within minutes during add/drop. An overnight batch is fine in July. It isn't fine in the second week of term.
6. Log every action. Every class created, student added or removed and class archived should carry a timestamp and the source of the change.

Here is how the same SIS data typically maps onto each platform:

Do new Teams or Moodle features change any of this?

Microsoft keeps adding features to Teams for Education, and Moodle releases new versions on a regular cycle. It's tempting to evaluate each one on its own merits: a reworked assignments view, new grading options, AI-assisted tools. Each release brings a new round of "should we turn this on?"

The pattern we see across institutions is simpler. Features built on top of a class only work when the class itself is right. Assignments go to the wrong students if the roster is stale. A Class Notebook is missing sections if students were added by hand after it was created. Grading workflows break when one course lives in three separate teams.

So the most useful question about any new feature isn't whether to enable it, but whether the data underneath it is reliable. If it is, you can adopt new features as they arrive. If your team still fixes rosters by hand every week, fix that first. The platforms will keep changing; the SIS remains the reference.

How LS2 approaches it

LS2 builds one integration per platform. Each reads from the institution's SIS and follows the same principles: one direction, stable identifiers, changes propagated within minutes and an audit log of every action. All three work with Omnivox, Clara, COBA, Banner, PeopleSoft Campus Solutions, Workday Student and Jenzabar.

• Teameo creates every SIS class as a Microsoft Teams class team, keeps membership in sync, merges cross-listed sections into one team with a shared Class Notebook and archives teams at the end of term according to the institution's policy.
• Classeo does the same for Moodle: course provisioning, enrollment sync, meta-courses for cross-listed sections and end-of-term archiving, on Moodle 3.9 LTS, 4.1 LTS, 4.3, 4.4 and 4.5.
• Calendo writes class schedules into Microsoft Teams, Outlook and Google Calendar, as well as Moodle and Blackboard calendars, so a room change in the SIS shows up where students actually look.

Institutions choose the products that match their platforms, and each one is sold separately. More than 50 higher-education institutions run at least one of them, and LS2 is a Microsoft Partner for higher education. To see how these pieces fit into a broader stack, read our guide to higher education software and our page on class management software. If you're planning the project itself, From contract to first class: a realistic SIS integration rollout plan covers the timeline step by step.