Design Decisions

The first place to start when building an Edlink integration is with a few high level design decisions. These decisions will help guide the rest of the integration process as well as the operational processes that follow.

The reality is that this guide could be infinitely long if we tried to cover every possible decision you might need to make. Instead, we'll focus on the most common decisions that need to be made when integrating with Edlink and pose them to you in the form of questions to consider.

This list isn't meant to be comprehensive, but it should give you a good starting point for thinking about your integration.

Offering Integrations and Getting Schools Connected

In this section, we'll explore the following three questions:

• Will we offer integrations to all customers or only to a subset (e.g. premium customers)?
• When and how will we get schools onboarded?
• What will we do about customers with existing data in our system?

Offering Integrations to Customers

Knowing which customers you want to offer integrations to is an important first step. There are costs (both in terms of time and money) associated with offering integrations, so you'll want to make sure you're offering the in alignment with your business goals. Here's some advice:

• Be careful about offering integrations to schools where only a single teacher is using your product. The cost of integration might not be worth the benefit.
• Providing integrations to free users can be expensive. Consider offering integrations only to paying customers as a way to provide additional value.

Onboarding Schools

Depending on how many schools you're planning to onboard, you might want to consider different strategies for getting them connected. With only a handful of districts and universities (let's say, fewer than 50), you can probably just stick to a manual onboarding process using our out-of-the-box onboarding flow. It's resonable that your team can guide each school through the process of onboarding and help them get connected.

For larger numbers, you might want to consider a more self-service process. This will likely involve more tightly integrating the onboarding flow with your existing platform and systems to stay organized. Check out our guide on Onboarding at Scale for more information.

Data Migration

Migration of existing data is a common challenge (and often one of the most painful parts) of integrating with any new system. It's important to think about how you'll handle this before you start writing code. There are a few different strategies you might consider:

• No Migration: If data continuity isn't important (or your product doesn't store much data), then you might just consider starting fresh with the new data. A great time to do this is over winter or summer break when schools are out of session and classes are changing anyway.
• One Time Migration: This strategy involves the creation of a mapping table between your old data and your new data (or just the relevant entity IDs). You'll need to write a script to migrate the data from your old system to Edlink. This is often the simplest strategy, but it can be complex at scale (or if the data is scattered and disorganized). Edlink can often help with this process, providing assistance with the generation fo the mapping table.
• Continuous Migration: This isn't necessarily a migration, per se, but rather a strategy for keeping data in sync between your system and Edlink. This is often the most complex strategy in the long term, but it can be easier in the short term. Basically, you'll need to keep track of which data came from Edlink and which data came from your system. As you sync data from Edlink, you'll have to match it up on the fly with the data in your system.

Syncing Roster Data

In this section, we'll explore the next four questions:

• How will we go about syncing roster data? Full syncs? Incremental syncs?
• What is the minimum level of data that we need in order for our platform to function?
• What happens when we don't get the necessary data?
• Do we want to allow customer to override data that is ingested from Edlink?

Syncing Roster Data

The biggest decision you'll have to make here is whether you want to sync a school's dataset in its entirety or sync individual classes as needed. There are valid use cases for both strategies, but you'll need to decide which one is right for your platform.

Typically, at scale, syncing the full dataset is the best strategy. This provides consistency for all schools and can allow you to shift compute resources to when they're not needed (i.e. syncing overnight) However, this can be a complex process, especially if you're dealing with a large number of schools.

At a smaller scale, syncing individual classes as needed can be a good strategy. This can be easier to implement and can provide a more responsive experience for teachers. However, it can be more complex to manage at scale because teachers will all want to sync their classes at roughly the same time (i.e. at the beginning of a new semester or new school day) and this process may overwhelm your servers.

Minimum Level of Data

It's important to think about the entities (e.g. schools, courses) and fields (e.g. name, start date) that you need in order for your platform to properly function. Schools don't always have all the data you need, organized in the way you want, available in a reasonable timeframe. You'll need to think about how you'll handle missing data.

Here are a few ideas to consider:

• Always have a fallback approach for when data is not available.
• Consider adding a prompt to your UI that asks users to fill in missing data (e.g. "What grade level are you in?").

Overriding Data

This is a tricky one - it can be easy to want to allow users to make changes to data that is ingested from Edlink, but it can also be a slippery slope. If you allow users to change data that is ingested from Edlink, you'll need to think about how you'll handle changes to that data in the future. What happens when you want to revert to Edlink's version? What happens when Edlink's version changes? For example, consider the following situation:

• A teacher syncs a class from their LMS via Edlink.
• A student is added (manually) to the class in your platform.
• The student completes an assignment in your platform.
• There is nowhere to sync the grade back to the LMS because the student was not in the class in the LMS.

In general, we advise clients to not allow users to edit data that is imported from Edlink. For example, if you sync a class from Edlink and a student is not in that class, you should not allow the user to add that student to the class. Instead, you should prompt the user to edit the class in their LMS or SIS instead.

Assignment & Gradebook Functionality

In this section, we'll explore the final three questions:

• What assignment & grade functionality do we want to integrate with external platforms?
• Will the learning experience take place on my platform or on the LMS?
• What functionality in our platform will need to change to support our integration?

Assignment & Grade Functionality

In general, LMS and SIS systems try to provide a generic assignment and gradebook solution that can handle a wide variety of content in a relatively shallow way. What this means is that you should consider the interface between your product and the LMS or SIS. What works best for most clients is to treat the data provider as a "source of truth" that holds:

• The assignment & metadata (e.g. due date, point value)
• A link to the assignment in your platform
• The submission status
• The final grade for the assignment

Most LMS systems don't have a great way to represent:

• Complicated content types (e.g. interactive content)
• Rich feedback (e.g. video feedback)
• Grading scales (e.g. rubrics)
• Heavy personalization of coursework (e.g. adaptive learning)
• Complex reporting (e.g. learning analytics, time on task)

You'll need to think about how you'll handle these cases in your platform, and think about how to "simplify" some of the richer aspects of your platform to fit into the LMS or SIS. What this might look like in practice is distilling down a complex rubric into a single score to return to the LMS or SIS.