Common Pitfalls of LMS Integration

by Jordan Clark

If you're a developer or publisher in edtech, you've probably been asked about LMS integration from your clients. If you've never done an integration before or are trying to integrate with a new platform, you're probably going to look up documentation and guides on how to write them into your app. Unfortunately, almost every system has quirks or problems that aren't immediately evident from the documentation. Additionally, there are many considerations that are easily overlooked when trying to handle several integrations at once.

Companies that are just getting started with LMS integration may run into some common pitfalls. Many of these challenges aren't immediately apparent and can cause serious delays in releasing a new integration. Here's a shortlist of some of the most typical, but frustrating roadblocks you could run into.

1. Using an email address to identify students

In many platforms, users are identified in a database through email addresses. In short, this is a bad idea, especially for apps that integrate with learning management systems. Email addresses that are attached to users in an LMS are typically unverified. Depending on how the LMS is configured, an individual's email address can be changed by an administrator or even by themselves.

This means that a user with any access to change an email address in an LMS or other integrated platform can change their email address to anything. For example, a student could change their email address to match that of the teacher. If your system is relying on the user's email address to identify them, the malicious user could sign into your platform with their LMS account, and actually be logged in on your app as the user whose email address they've impersonated.

This can present a huge security vulnerability when implementing SSO through an LMS. The easiest way to avoid this problem is to simply not match users in your database to LMS email addresses. The address should only be an attribute of the user's profile, much like a name. We recommend using the user's Canvas ID joined with the ID of the Canvas environment. This way, you platform will know exactly that each user from the LMS that is listed in your database in unique.

2. Not every LMS supports LTI® in the same way

The LTI standard is supported by several major learning management systems. One of the biggest benefits that LTI touts is the ability to incorporate an LTI-compliant app into any platform that supports the standard. The idea is that if you write an LTI integration for one platform, you app will be compliant for all others. Unfortunately, this is rarely the case.

LTI-compliant apps generally support one of the three major versions of the LTI release: LTI v1.0, LTI v1.1, and LTI v1.3 with LTI Advantage services. The most recent version of LTI is v1.3. However, not all major LMSs support this version. Schoology only supports up to LTI v1.1. Google Classroom and Microsoft Teams don't support the LTI standard at all. Thus, simply having an LTI app won't be enough if the schools you work with don't have an LMS that supports the standard.

3. Building an integration is just one step, managing the integration is a whole other animal

Just writing an integration is not enough. There are several other considerations you have to take into account when you have users authenticate into your platform via an LMS.

For example, each LMS has a different way to treat user properties, such as assigned roles. In some LMS's, such as Google Classroom, a teacher in one class can be a student in another. In that situation, how do you treat this user's role in your own platform? Some LMSs don't even require email addresses. What do you do with these users in your database?

Additionally, how do you determine which users from a school should have access to your app? If only a a specific school at a district or section of classes has purchased access, how do you restrict other users from that LMS from interacting with your app?

These are the types of questions you need to ask yourself when you're designing the architecture of your LMS integrations. There's not a right answer to any of these, but they can cause serious delays in the implementation of your platform if you don't plan ahead.

4. Onboarding schools can be challenging

One of the hardest parts of getting schools to adopt your platform is to convince school IT admins to complete the integration. Many types of data integrations are not straightforward and can take hours out of an IT admins day to complete.

If you don't make the process easy for administrators, it could cause delays in getting teachers and students onto your platform and diminish the user experience. Furthermore, if the integration needs to be updated or if a configuration change by the school disables the connection, it can be difficult and confusing for the admin to make the necessary corrections to reconnect.

Additionally, integrations typically require exchanging sensitive data, such as LTI and API secret keys. These keys can give third-party apps the ability to read and write to certain endpoints in the school's LMS. If your platform doesn't have a secure method for school administrators to exchange those keys with your platform and to store them securely, it could expose their LMS to serious danger.

Read More on Integration

Here are other articles we’ve written on building integrations to help you on your journey:

If you're looking for a partner who can help guide you through developing LMS integrations (like these), then let’s introduce ourselves. We’re Edlink!