Integration from SIS to Canvas using Canvas APIs (e.g. Ellucian ILP) - data being overwritten

[EricaAustin]

We are using the Canvas-delivered APIs to integrate course and enrollment information from our SIS to Canvas. Note that I'm referring to the APIs that are direct, one-off calls to update data in Canvas, and not the API call you can use to transfer csv files for integration, which is basically a replacement for sftp.

Since switching to the API integration, we've found that sticky fields are no longer honored in Canvas, and any changes triggered to send to Canvas are automatically overwriting the data in Canvas that may have been changed in the UI by faculty (e.g. course date overrides, course titles, etc.).

Is anyone else experiencing this as well?

Note: We are using Ellucian ILP, but I don't believe the issue is isolated to that product but rather lies with the Canvas APIs. We have also put some complicated workarounds in place to mitigate the issue, but it's not ideal and not feasible long-term as we look to expand our API usage overall with other integrations.

[MikeBrinkman]

We're interested in doing this as well, good to know that we should look out for this!

[patfm]

Hi,

We have a similar problem with ILP 5 per your note.   Our names fields are currently populated by our Identity Management system, Okta, including preferred name.  In fact we are delaying our full implementation of ILP due to the fact that it would replace the name fields with Banner name fields.  In most recent version of ILP 5 you can now toggle OFF the sending of preferred name, which is great, but Okta also fills the 'first name' field in Canvas with the preferred nickname--so we assume ILP will wipe that out and fill it with the Banner 'first name'.    We would be interested to find out if there are any workarounds that any schools have put in place.

[zowada-a]

Hi,

We are having a huge problem with dates being overwritten (Banner is our SIS, and using ILP over to Canvas).  Teachers change the course dates to be earlier at the beginning, or later at the end, and any change in enrollment in Banner overwrites/resets these dates.  This is ongoing and an issue, and I am trying to see if anyone knows how to set "something" in Banner or in ILP so that enrollment changes don't trigger date changes.

Has anyone had any luck with this?

Thanks!
Sam

[hmcneill]

I'm also interested in a solution for this issue. We are currently using CSV batch files from Banner but are considering moving to API calls in the future. Sticky fields are important to our design, particularly for section dates. 

[bcline]

Hi,

I noticed this post looking for another topic.  Hope it's resolved, if not here is some information that might help:

Once a matching term is set-up in Canvas with your SIS ID for the term and the term is added to the SIS config in ILP with the terms refreshed, (it's best) to run one open bulk job for the new term to bring over anything that is already there.  After that, as long as the term is in the SIS config, ILP should not be washing the sections (dates) - but this would happen if you were re-running the entire term over and over again as a bulk job.

Once ILP has created the sections in Canvas, new enrollments should run in the background (with a hiccup every once in a while that can be corrected with a one-off bulk job).

BCS

[Mikee]

This is a fundamental aspect of your integration design.

A key concept here is a 'source of truth' that should be followed. It sounds like this for you is not canvas. A potential way to look into this would be to add some access globally from the enrolment system so, for example, the subjects open two weeks before the subject starts. 

There may be legislative, probity, or financial requirements that need to be followed globally.

Integrations *can* be written to check if fields are not in sync or have been updated before applying changes (deltas) but these are much much harder to design, deploy, support, and take far longer to run.

I'd suggest looking at where the dates are coming from, and determining if some logic can be added to avoid you needing to modify the dates at all - saving you time, and maintaining the 'truth' of the source enrolment in your Student info system.

[Mikee]

Can I ask what your role is @EricaAustin ?
It may be that the BA or equivalent at your organisation (or perhaps your CSM if this was delivered by canvas) is able to share the reason why the dates are set the way they are by the integration, and what process(es) you have internally that need to be followed to modify these 🤓

[EricaAustin]

I am that role (I'm actually a director/programmer/analyst/dba/etc. all in one). I set up the integration and understand what fields are being used.

The cause for this issue as posted was a flaw/limitation in the original design of the Canvas API. After lobbying for a year, we finally got Canvas to understand that their API did not contain any mechanism to honor (or not - whatever you choose) sticky fields in the way that their legacy csv integrations do, and this was a problem.

Canvas has since implemented this functionality in their APIs. We are now waiting for our vendor to modify their integration product/middleware for our ERP so that we can take advantage of the new API settings for sticky fields in Canvas.

[arlin_burton]

I have been using the Ellucian ETHOS and ILP for 2 years,

With Ellucian Ethos Intergration the Registrar office can now control the LMS (Canvas).

You will need to work closer with the Registrar office to explain they are now incharge when courses are created, crosslisted and deleted in Canvas

The simplest way to lock Canvas is to remove the term ID number from the ILP SYS file.

of corse this will stop enrollments for the term. the other option is to have the Registrar extend the term dates.

Gene 

[ErinDemse]

We are also experiencing issues with the dates being overwritten for the term. Did you ever get this resolved?

[jb2483929]

@EricaAustin Did you come up with any solutions to this? I don't think it is part of the ILP product yet. We are new to Canvas (although not new to ILP) and just coming across these major limitations).