“Man! I LOVE this tool!”

Have you discovered a tool that changes everything in your teaching? Maybe it makes your grading simpler or easier, or maybe it provides a more interesting or thought-provoking way to engage your students with the material. 

You may have even heard that the tool you like can integrate with your learning management system (LMS), and are wondering about the process of getting the tool adopted on a larger scale for your department, college, or even the whole institution.

Here’s a handy guide to everything “third-party”, and how you can best make use of these resources in your class.

About Third-Party tools

A third-party tool is a product that is not administered by an LMS; it exists outside the system’s universe. Some tools are University-supported, meaning that staff and/or faculty have administrative access to it and are able to troubleshoot problems from the back end, while others are not. Some tools are accessible directly from within an LMS, which means there is an “integration” which allows information to be directly passed back and forth from the external tool to the LMS. For example, some products can pass grades on to the LMS gradebook directly from the tool. The administrators’ ability to administer a tool does not affect its usefulness or functionality, but it does limit their ability to help if you run into problems! You can use a third-party tool if you would like, but if the system can’t support the tool internally, you’re on your own.

As far as third-party tools go, an integration provides the best experience for students, as it passes information back and forth between the two systems, and students can remain in the LMS to complete the work rather than logging in through another website. 

Integrations sound great. How can I get one?

If you are using a tool often, and it’s become an integral part of your course, you might be wondering how you get it integrated into your LMS, or if an integration is even possible. The first step in getting a new integration is checking if your chosen tool has one available. Most universities use the LTI system, which aptly stands for Learning Tools Interoperability, for processing integrations. You can easily find out if an LTI integration is available by doing a Web search for “[tool name] LTI.” This will bring up the vendor’s page detailing what is available, and many even provide instructions for system administrators on how to set up the integration. At DePaul, instructors can request that a third-party tool with an LTI feature be integrated into the LMS using this form. If you are asking for an integration, you will likely be asked to provide: 

• Name of the tool
• Name and contact information for the customer representative for the tool
• Is this a tool that is already being used at your institution?
• What is the intended scale of use? Is this tool going to be used just by the requester or by a larger group of faculty?
• What does this tool do, and what will it be used for?

You might be thinking, “Great! I’m asking about this right now!” But when you do, here is where things get more complicated.

The Technology Adoption Process

Because a technology integration at the university level has the potential to be used by many faculty, staff and students, it must undergo a rigorous vetting process to make sure that the tool:

• has a demonstrated value to multiple users, such as an entire department, college, or the university as a whole.
• does not recreate a function that already exists in the LMS.
• will work as intended if not better inside the system, and there will not be any loss of functionality compared to using the tool on the Web.
• will not interfere with any other existing integrations.
• passes a security review, to make sure that it is not collecting or sharing any information with outside parties that it is not supposed to. (Especially with student information, there are VERY specific rules on where it can and cannot go.)
• does not create any security holes in University systems that might provide access to unauthorized third parties.

Technology vetting is usually handled by a university’s Information Services department. If the application is widely used, and there is the possibility of application across the entire institution, a team vets it as an “enterprise” (large-scale) application. The team will determine if it is the best-fit solution for the problem, if the cost is justified for creating the integration and offering it everywhere, or if there are any existing products that perform the same function. In many cases, the team will review the product in question and usually also evaluate some other similar products to make sure to find the best, most cost-effective solution.

In addition to the security review, the tool may need additional rollout steps. For example, the tool may create data feeds, or need access to existing feeds. It might be enabled with SSO (Single Sign-On), so that logging into the LMS will also allow the student to pass through to the tool without logging on separately with a different account. If the integration is not a simple plug and play via LTI, it might require creating an API (Application Programming Interface) to allow the tool to talk with other systems correctly.

If a tool is just an add-on or an integration into an existing service or application, it can often be configured quickly without a full review, as they are small changes to an already-vetted product. But for larger or more radical applications, it can easily take six months to a year before seeing the full integration in your LMS.

Even once a tool is approved, you may not be aware of it right away, as there is an initial need for support and documentation for new users. Many rollouts may be “soft” while the first batch of users get used to the tool and provide feedback before it is announced for university-wide adoption (which can also spur another round of reviews…) All this suffices to say, the rollout process usually isn’t quick!

But what if I need it now?

Most of an institution’s technology needs are known and anticipated beforehand, and so they can be planned out in advance. This is why you often get notices from your information services department that something is changing months in advance of the actual change. This also allows them to make sure they will easily meet any deadlines, given plenty of time to plan. 

Sometimes a project needs to be fast-tracked, but this priority is usually based on need. For example, student needs (and the law) often dictate that captioning must be available for all hosted video content. An immediate accessibility concern makes this sort of project one that cannot wait. It’s also important enough to leapfrog many others in the priority list.

Still, it’s important to distinguish between fast-tracked projects that were planned or expected, versus those unplanned events that arise and force a response. Accessibility services are planned for and re-evaluated every few years. When they are evaluated, the student experience is a top priority, and they obviously get fast-tracked over other projects. But what do we do when the unexpected occurs?

The Covid-19 pandemic was an extraordinary series of events that demanded immediate and unplanned responses to brand new technology needs. For example, before the pandemic faculty and students here were on separate email servers at DePaul, which meant that there were some tools just available to faculty, such as Zoom, because licenses are server-based. The sudden need for the entire University to go online with a few days’ notice meant we would need to pay for two complete enterprise Zoom licenses (one for faculty and the other for students). 

Instead, our information services department made the brilliant move of putting all the students onto the same email server as faculty. This opened up a host of tools to student access and allowed us to continue using Zoom for classes, while also allowing students to be able to use it to meet with one another. In case of emergencies, it is possible to accelerate a tech adoption on tight deadlines, but this requires an enormous amount of coordination and is not undertaken without dire need.

I still want to use the tool. What now?

If you’re still interested in having a tool integrated into your LMS, you now have a better idea of what to expect. Let’s break down the steps you can follow to ask for an integration, and the steps it will follow if it is approved.

1. Ask for the integration. It may have a request form, like this one we use at DePaul.
2. The tool, and potentially some competitors, will be evaluated for best fit to make sure they are satisfying a perceived need and are cost effective.
3. The tool undergoes a security review.
4. The tool may receive additional review, depending on its needs (SSO, data feeds, APIs, etc.)
5. The tool is “soft-launched,” as the first requestors get access to the tool, documentation is created, and initial feedback is received.
6. A greater announcement is made to the general community about the availability of the tool and its capabilities, and training may be provided in the future.

As mentioned before, this process can often take six months to a year, depending on the importance of the project. The more you are able to plan ahead, the less disruptive the process can be.

So if you’ve been working with something exciting, don’t hide it! You might be discovering the next big thing for your classes. While we can’t promise that every proposed integration will come through the process, many do, and they have the potential to change the game for instructors University-wide. Keep exploring! We can’t wait to see what you come up with.