Feedback/Thoughts on Exceptions (with Subaccounts)

Thought I'd give some feedback from my playing with it today...

So I am about to do an install, which I need to just give to one of my branches of my Subaccount structure. We don't have this turned on for live yet, just beta, but I went to look at it, as I started the install. It is a 1.3 app, so no problems there.

I am going to, currently, have to do it just on a subaccount level, which got me thinking about a few of the other apps we have done this with in the past. I looked at one of their branches and I can move it further down the branch, but I couldn't move it up the branch (so like if I wanted to move it from one subaccount to root level).

This would be really handy, because we have had situations where one school (its own subaccount) invested in a product, but then we went to a site-wide account. I would now have to remove it from the one subaccount and then reinstall it on root. If I could just adjust this, it would be helpful.

Let's see if I can explain it a little with pictures:

As you can see, this is currently installed in Mathematics subaccount, which is actually on a subaccount for Engineering and Computational college. What if Engineering bought into this product, so it expanded out of Math? What if I wanted to move it to the root? This would be helpful to be able to slide it or adjust what level it is at. (Our root is Southern Utah University, so it did not come up.)

Versus, here is a picture of an LTI we have installed at Root:

English is another department/subaccount we have. I can't pick that subaccount, even though this one is installed on the Root level:

When I scroll, it does show me some of my Subaccounts, but it truncates at A (since we have so many I assume):

So I couldn't even scroll to English, if I wanted to get to it. My search didn't find it.

Okay hopefully this explains well enough, but let me know if there are any follow up questions on this.

Find more posts tagged with

Accepted answers

All comments

AlexisNast

Thanks for sharing this! It's something we thought about and weren't sure of the need for, but have been investigating feasibility of a feature to help with it. Definitely interested if others have the same scenario or if there are any other nuances to it that we should be aware of.

AlexisNast

Thinking about this more, something I'm curious about is the need to move the installation "down" a level or to a level other than the root account. My thought is that if it gets moved to the root account, then you could do whatever controls you need via exceptions. Would that meet the need or is there something I'm missing around why you'd want the deploy at a sub-account rather than the root with an exception?

Tasha_Biesinger

There was a survey about this new functionality (a few weeks ago?) and I provided some feedback there about this interface and specifically around finding the right subaccounts vs. courses. We have a decently deep subaccount structure and trying to find just the right thing(s) in that tiny search window was tough and the courses were definitely more in the way than not but maybe don't have them appear by default or don't show at all unless I click something to say I'm looking for course(s). Some of our subaccounts have the same names as well (yeah, I know) so that added a little difficulty finding the right subaccount. I'd love some options here for maybe clicking a button to pop out of that tiny window into e.g., full screen where our accounts structures were visible, expandable, and selectable. I forget now if we can search by our institutional account ID if not, it should be built in along with the Canvas account ID that Jill pointed out doesn't work.

I am really excited for this functionality in Prod so that we can deploy 'course-level' integrations that don't become little viruses that can be copied from this course to that course when it should have only ever been in this course.

leward

So, here's a question. With the ability to make exceptions, why not just deploy all tools to the root? For unrestricted tools, the deploy would be available with no exceptions. For restricted tools, the root deploy would be set to unavailable, and exceptions could be added to any subaccount or course in the hierarchy. Then, if the access to a restricted tool needs to move up or to a different branch of the hierachy, no problem. The deploy remains as is and the exceptions change. Since many tool providers are requiring deployment IDs, this could simplify things considerably.

An even simpler approach would be to eliminate subaccount and course deploys all together. When 1.3 a tool is enabled, a root deploy is created in the unavailable state. The admin would then either make it available to all users, or leave as unavailable and add exceptions. This might not work for situations where different customizations are needed in each deploy, but boy, it sure would make app management easier.