Upper limit to number of context controls/exceptions on a deployment?

We have a potential use case where the number of necessary exceptions could be in the tens of thousands (hundreds of thousands long term). Is this feature able to support that significant of a number?

I expect the UI will likely become unruly for this tool if we go forward, and we would likely be using the API endpoints to accomplish this task. I know that the API is currently considered "beta", but is it safe to assume that the base functionality (creating/modifying/deleting) will be available to use? I recognize that the exact formatting/syntax may change.

Thank you!

Find more posts tagged with

Accepted answers

All comments

AlexisNast

We did performance testing for tens of thousands, but we did not get up to hundreds of thousands. I'd definitely recommend testing it out in beta first. And yes, the UX will get ugly in this case! The UX limits you to adding 100 exceptions at a time, so you'd want to use the API for efficiency if nothing else.

I'm very interested to learn about the use-case here - I assume these will be course-level exceptions, but I'm interested in understanding why sub-accounts won't work in this case so we can continue to explore if there are ways to expand this feature that are cleaner.

jmerlenbach2

Thanks Alexis! The use case surrounds making a specific LTI available/not-available in courses based on the modality (in seat vs hybrid vs online). Our sub-account structure doesn't reflect modality of courses - in reality nothing in Canvas does for us, so this would be course level exceptions that we would loop through a list to set.

For this case, because no Canvas data exists anywhere about modality for us, I'm not sure an expansion to the feature would help.

But, if there were a way for us to set rules for exceptions, that could be pretty nifty. For example, if we had a course each semester where we knew that the course name/code/SIS ID was going to have a specific feature, if we could write something like RegEx that the availability could interpret and apply wholesale, that would save us from having to add specific exceptions every semester for that individual course offering. For example, if Chem-1100 always needs this tool, but no other chem course in that sub-account, we could write a rule about it. Or, teacher based ("Any course that Professor X teaches needs tool Y set available for). I think that would be simpler - these tools tend to be used by a specific faculty member.