Differences Between Providers

Every LMS, SIS, etc. is not created equal. They all have different features, different ways of doing things, and different ways of accessing their data.

At its core, Edlink is an abstraction layer and no abstraction can be better than the underlying data it abstracts. This is why it is important to understand the differences between the data models of the various providers that Edlink integrates with. While Edlink tries to make it as easy as possible to integrate with any of these systems, there are some differences that you should be aware of.

Data Model Differences

Not all providers will have the same entities available. We do our best to normalize the providers into a common model, but we cannot materialize data out of thin air.

For example, some LMS providers do not have the concept of "schools" in their platform, notably, Google Classroom. In these cases, Edlink will not be able to provide school-level data for these providers. The schools endpoint will still be available, but it will return an empty list.

Other common data model limitations relate to the availability of fields for a given provider. For example, an SIS may not store an entire assignment but instead the metadata it needs to store grades for it. In this case, you're likely to receive only a subset of the fields that you would expect for an assignment (e.g. title and due date, but not description or attachments). When creating an assignment in the SIS, you may find that certain properties are not supported and will be ignored (with warnings).

We have also made some design decisions along the way to accommodate these differences which you may need to take into account.

• Edlink will use defaults for these properties where appropriate when creating or updating resources.
• You can enable various Edlink feature flags to modify the behavior of Edlink to better suit your needs.
• We have done a lot of work to better reflect the "intent" of some of our API calls rather than the literal implementation of them. For example, when returning a grade for an assignment, we may first attempt to submit it on behalf of the student, if that action makes sense given the user experience in the LMS or SIS.

What Solutions Can Edlink Provide?

If you're facing a data issue (e.g. some systems are missing the field you want), chances are you're not the only one who has run into it before. Over the years, we've built up a number of solutions to the most common (or most painful) problems.

In particular, there are two major features that we can use to help you get the data that you need (in the format that you need it):

• Data Enrichment: We can enrich the data that we receive from the provider with additional data that we have access to. This can be as simple as adding a field or as complex as calculating a new value based on the existing data.
• Data Transformation: We can transform the data that we receive from the provider into the format that you need. This can be as simple as renaming a field or as complex as combining data from multiple sources.

API Functionality Differences

Beyond the data model, the functionality exposed by each provider's API can vary. This means that while an endpoint may exist in the Edlink API, the underlying provider may not support that action.

• CRUD Operations: Not all providers support full Create, Read, Update, and Delete operations on all resources. For example, Google Classroom announcements are read-only and cannot be created via the API. Similarly, some providers implement "soft deletes" (marking an item as deleted but not removing it), while others perform "hard deletes."
• Submission Lifecycle: The process for submitting, grading, and returning student work differs between systems. Actions like reclaiming a submission (reclaim) or returning it to a student (return) are not universally supported. In these cases, the Edlink API will return an UNSUPPORTED_OPERATION error, which your application should handle gracefully.
• Pagination: While Edlink standardizes on cursor-based pagination, some endpoints connected to specific LMSs may have limitations. The most reliable way to paginate is to always use the $next URL provided in the API response.

When an action is not supported, the Edlink API will typically return a 501 Not Implemented error. It's important to build your application to handle these responses. There may also be situations in which an action is only partially supported (e.g., certain fields cannot be updated). In these cases, the API will typically return a warning with details about the unsupported fields. In other cases, the API may throw an error, typically when the updated property is critical to the operation.

User Experience Differences

The technical differences in provider APIs often translate to tangible differences in the experience for your end-users (teachers and students). Managing these expectations is key to a successful integration.

• Data Latency: Roster information is typically synced on a schedule (e.g., once every 24 hours). A teacher who adds a student to their SIS will not see that student appear in your application in real-time. Coursework and grade passback, however, are usually performed on-demand and appear much more quickly.
• Cross-Listed Sections: In systems like Canvas and Schoology, teachers can merge multiple sections into a single "course." While this appears as one course in the LMS UI, Edlink correctly represents them as distinct classes. This means creating an assignment for a cross-listed course requires a special workflow using the parent_id property to link the assignments together.
• "Phantom" Submissions: To provide a consistent developer experience, Edlink creates a submission object for every student as soon as an assignment is created, even before the student has submitted any work. In the native LMS, a submission object might not exist until the student interacts with the assignment.
• LTI Tool Placement: The way your application is launched via LTI can vary significantly between each LMS. It may appear in the course navigation, as an option when creating an assignment, or in a user's app center. This can affect the context your application receives and the user's workflow.