10 Reasons Why LMS Integrations Are Too Entangling to Solve

The pandemic slingshot third-party elearning apps into keeping up with the technological requirements of schools. Today, it’s even more important than ever for these companies to nail down an integration strategy and provide a wider range of connections for users.

LMS integration, in particular, has always been challenging for online learning apps. It always requires a ton of development effort upfront and can place an ongoing burden on unsuspecting companies. That load of development time would otherwise be spent improving an edtech company’s core product. Here’s why LMS integrations are so difficult!

1. Prioritizing which LMS to integrate into is too complex.

There are dozens of different LMSs available on the market – coming and going every year. There are 100,000+ schools in the United States, and they all rely on some form of technology for their students and faculty to complete homework, communicate, and track grades.

Through the rise and fall of system popularity, the decision on which integration to prioritize becomes harder and harder for companies to make. And this struggle is amplified when trying to complete integrations in a timely manner to remain competitive. Just one integration could take several months. Add in 5 to 10 more connections to build and a company is looking at years of development work – time that could be better spent elsewhere.

2. Choosing how to integrate with an LMS is too overwhelming.

There are too many options and not a lot of subject area experts to provide the necessary knowledge and guidance for companies (we couldn’t name anyone that’s an integration expert for edtech!).

Edtech apps typically send developers off on a task like this: "A large district wants Canvas integration. Figure out how to do that." So, developers quickly discover that Canvas (for example) has 2 different APIs, several supported versions of LTI, QTI, Common Cartridge, and so on.

With no subject experts, a lack of good examples, poor documentation, and the underlying worry that the company will have to navigate this process for every LMS – many teams just decide to throw in the towel on LMS integrations. When it comes to it, companies suffer from classic analysis paralysis because of the options.

3. Each LMS has a different data model and feature set. Abstraction to manage integrations needs intense planning and programming skills.

Some LMSs have course sections, some don't. Some LMSs require user email addresses, some don't. Some LMSs allow the school administrator to define custom user roles, some don't. Understanding all of the unique edge cases is a challenge in and of itself. Accounting for these edge cases in development is a different story altogether.

Designing a system that is abstract enough to handle the data models in every LMS requires a significant effort in planning and programming. Many learning apps were never designed to handle things like third-party authentication, contextual user roles, or complex organizational hierarchies.

4. Some LMSs are cloud-hosted. And some LMSs are self-hosted. Learning for each integration edge case becomes impossible.

Blackboard, Canvas, Moodle, and Brightspace are systems that can be hosted by a school or university on their own cloud provider (think AWS). When schools host their own LMS, edtech apps are in for a variety of new edge cases unsuspectingly.

If third-party apps use a school’s LMS for SSO or API integration, the apps will have to take custom domains into consideration. Moodle and Canvas allow users to make custom modifications since both are open-source LMSs.

Another major headache for edtech app developers is the different LMS versions a school may run. When schools self-host, the school no longer receives automatic updates. The school has to release new versions to students and staff on the school’s schedule. Some schools and universities can be running LMS systems that are years behind, and lack important features that edtech developers rely upon for integrations.

5. Configuring integrations can lead to accidental security vulnerabilities.

School administrators are busy enough as it is and don't have the time to navigate a lengthy integration process. LMS setups vary wildly and there are dozens of different configurations that can be required between the various LMSs. Schools may self-host their LMS and some may use a vanity URL for the school’s teachers and students to get quicker access.

In addition, most methods require the exchanging of sensitive data like API client and secret keys, or LTI consumer and secret keys. Generating these keys within the LMS and then sending them via email is extremely insecure, but unfortunately, this happens all the time. The fact is, many school administrators (and even edtech app’s implementation staff) don't understand how sensitive these keys can be, or what they can be used to do.

6. Testing integrations is tricky (and potentially costly).

Schools often run different LMS versions, have different organizational hierarchies, or have different user roles. It can be hard to set up any sort of testing environment to build and test an app’s integrations.

Some systems like Blackboard, Canvas, and Moodle must run on an edtech company’s own servers – requiring time and money to get up and running. Others like Brightspace and Microsoft require that edtech companies have partnerships to get access to testing environments. In either case, even getting to the point where developers can start working on integration is a time-consuming (and potentially costly!) process.

7. Access control is a massive challenge.

Adding third-party authentication can present some challenges with controlling access to elearning apps. For example, when an app adds a “Sign in with Google” button, the app is exposing itself to any Google user. There is no way to tell Google ahead of time that you're only interested in logins coming from a particular organization.

Most companies rely on something like a user's email domain to determine the organization that the user is coming from. This is riddled with problems. What if the application is only meant to allow logins from 1 elementary school within a larger district? How do apps limit this? Answer: they can’t do this easily.

8. Apps may have to reconcile LMS data with SIS data.

When apps integrate with a method like LTI, the app will often want to know about users ahead of time. To do this, it’s required to have either an API or SIS connection. Typically, companies will also choose to roster students and enrollments with a platform like ClassLink or Clever.

Now that users and courses are pre-provisioned, you have to match up LTI launches with a user coming from Clever or ClassLink. This can be a very hard problem. Finding common identifiers between the LMS and the SIS is tricky.

9. Self-hosted LMSs can open users up to security vulnerabilities.

Email provides are the most common form of user authentication on the web. Logging in with an email address and password is no doubt a familiar experience. Since emails are allegedly unique, they provide a good way to identify unique accounts. The problem occurs when elearning apps rely on a third-party authentication method to correctly inform the app about the user's email address.

For example: suppose a user signs up for a website with the email "you@ed.link". Later, the user clicks “Sign in With Google” using the same email address. The website will likely rely upon the user’s email address in order to identify them. This is okay – Google is reliable and secure. LMSs are not so reliable. Most systems allow developers to set any email as the user’s LMS email (even if the developer doesn't own the email address), users could set their email to be anything, and even use this mechanism to improperly gain access to others' accounts.

10. LMSs vary wildly in data formatting and consistency.

There is no blueprint for writing an LMS. The largest LMSs on the market have developed over the course of years or decades to meet the needs of users. As a result, there are no generally-accepted practices for modeling data in these complex systems.

Even something as straightforward as object IDs can prove to be rather complex. Some LMSs use auto-incrementing integers. Some use integers, but they're presented as strings. Some use random strings. More modern systems typically rely on globally unique identifiers. This can create confusion for developers for something as "simple" as importing a list of a user's courses.

For example, in Canvas, a user with an ID of 1 can be enrolled in a section with an ID of 1, which is contained by a course with an ID of 1, which is located within a school of (you guessed it) ID of 1.

To Wrap It Up

These points are all things to consider before developers jump head-first into the depths of LMS integration. It can seem deceptively easy to connect to these systems when a developer is staring down a large RFP.

Learn More on Integrations

If you’re interested to learn more about integrations and Edlink’s Unified API, here’re other articles we’ve written:

Set Up a Meeting

Ready to see if Edlink can help you on your integration journey? Email us at support@ed.link to set up a call.