How are your account(s) and sub-accounts structured?

[Chris_Beks]

When we started using Canvas a few years ago, we set up a pretty simple account and sub-account structure for our institution. Under the root account, we created a sub-account for Catalog, one for training courses, and one for migrated courses of the previous LMS.

However, as we went along, we are now discussing whether we should create further sub-accounts for colleges and schools for the following reasons:

1. External tools can be installed at the sub-account level, and with fewer users in a sub-account compared to the root account, it could save money on the paid third-party tools.
2. It could provide us with better, more accurate, and more detailed analytics for the sub-accounts
3. Eventually, some of the management of a sub-account could be delegated to a sub-account admin specifically assigned to that school or college, alleviating some of the duties of the root account admins and the help desk.

How do other institutions set this up? We're curious if you have/had different reasons for having sub-accounts for schools and colleges or if you would prefer a simplified setup. Are we looking at a more complicated setup when we shouldn't? Any insight for the community would be much appreciated.

[mzimmerman · Accepted solution]

Hi @Chris_Beks 

We have sub-accounts set up by college/school and then by subject (underneath the appropriate college) for exactly the reasons you describe: more granular analytics, the option for tools to be installed/integrated at the college level, the ability delegate some admin capabilities, etc.

[melodyc_lam · Accepted solution]

@Chris_Beks Welcome! This is a really good question.

Some context: I'm the Canvas Admin for a very large K-12 district with around 160K users and (currently) 186 schools. What I will say here may or may not work for your institution and your needs. 

In our district, we have subaccounts for each of our 186 schools. These schools are under a parent account representing their grade band (roughly Elementary, Middle, High, Specialty). We also have subaccounts for central office departments and also for 'staging' purposes (blueprinting, archival, etc)

Some reasons why you may want a "deeper" subaccount structure:

• Applying particular settings such as Canvas for Elementary to a subaccount
• LTI installation by subaccount (especially if only one school needs the LTI)
• Analytics is 'easier' (there are limitations still with Admin Analytics because we are so large, though)
• We can assign specialists that support particular grade bands to their assigned grade band to the parent subaccount which then lets them have access to all the child subaccounts.
• Assign subaccount admins for support.
• It's much easier to search for courses and users, and filter by terms since you can search within a subaccount (this is really huge for a district our size).
• Global Announcements can be sent to subaccounts specifically so that only a particular school or group of schools gets an announcement.
• Subaccount theming -- we don't do this but it is possible to theme each subaccount with a particular college's logo or requirements
• Archival of previous year's courses -- you can move courses into a "archive" subaccount to ensure that subaccount admins only see current term year courses.

Some things to think about as you're working through how you want this to work:

• You can only readjust the structure of your subaccounts using a SIS import file (even if you're not using a SIS).
  • If these subaccounts have courses in them and you're doing a huge re-alignment, this import may take a while.
  • Only one SIS import can run at a time and other SIS imports will be queued up, so if you are readjusting subaccounts, either do it a few at a time or stage the change during a lower period of activity in your instance.
• If you have a SIS and you have courses mapping to subaccounts, be aware that your SIS may undo some of your changes.
  • Make sure you use the "Process as UI Changes" checkbox so that this doesn't happen.
• Subaccount admins that are added within the UI can't be managed using a SIS import file.
  
  • Think about how you want to manage subaccount admins as an institution.
  • An option: you can have your subaccount admins manage the list themselves for their school.
• Think about your settings and feature options as they stand right now, and whether or not you want subaccount admins to be able to change these settings.
  • You may have to go back and lock settings do that they can't be changed by subaccount admins.
• Some permissions will only be available at the root level -- for example, subaccount admins can't act as another user unless you set up the permissions at the root level.

Let me know if you have any questions! Hope this helps 🙂

[Chris_Hofer · Accepted solution]

Hi there, @Chris_Beks ...

I can give you a couple examples from experiences I've had with sub-accounts.

My first example was when I worked at a Technical College in Wisconsin.  I'm not sure if this sub-account structure still exists the same way (it's been a couple years) as when I left, but this is what I recall:

• Sub-account 1 (Dean access)
  • Sub-sub-account A (Associate Dean access)
  • Sub-sub-account B (Associate Dean access)
  • Sub-sub-account C (Associate Dean access)
• Sub-account 2 (Dean access)
  • Sub-sub-account D (Associate Dean access)
  • Sub-sub-account E (Associate Dean access)
  • Sub-sub-account F (Associate Dean access)
• Sub-account 3 (Dean access)
  • Sub-sub-account G (Associate Dean access)
  • Sub-sub-account H (Associate Dean access)

As you can see from this configuration, we had three main sub-account, and then sub-sub-accounts under them.  Associate Deans could only see their own sub-sub-accounts (for example, an Associate Dean in B could not see the courses in C).  However, the Dean for a main sub-account had access to all courses in the sub-sub-accounts.  For example, the Dean for sub-account 1 could see the courses in A, B, and C ... but not for D, E, F, G, or H.  This helped for our ReadyGO (Cidi Labs) LTI integration so that Deans and Associate Deans could get reports for their own programs.

At my current job (an art college in Detroit), we have approximately 45-50 sub-accounts...none of which are nested within each other.  Each of these sub-accounts is their own separate program.  For example: LIBERAL ARTS, FOUNDATIONS, ILLUSTRATION, etc.  Our Chairs and Program Managers have access only to the sub-accounts they oversee (similar to my first example).  At some point, we may consider pairing down the number of sub-accounts we have to try and combine things a bit more, but that is a conversation we'll have to have with a number of different folks at my college.  We've been using DesignPLUS (also from Cidi Labs) to design course templates, and one goal we have is to provide customized template pages at the sub-account level for anyone in a specific program to import/add into their own course pages.  We also use Cidiscape (yet another Cidi Labs product), and although we haven't set up this part yet, we can set Cidiscape up for our Chairs and Program Managers to get important information about courses in the program areas.  We're also looking at possibly purchasing ReadyGO so that our Chairs and Program Managers can get a better idea on if our courses are ready for the start of a given semester.  And, we can ensure that they only have access to their own courses...all because of sub-accounts.

I hope my examples and use cases help in some way.  Looks like you've gotten some great feedback so far, and I look forward to seeing more people post their setups!

[mzimmerman · Accepted solution]

Hi @Chris_Beks 

We have sub-accounts set up by college/school and then by subject (underneath the appropriate college) for exactly the reasons you describe: more granular analytics, the option for tools to be installed/integrated at the college level, the ability delegate some admin capabilities, etc.

[Chris_Beks]

Thank you for your reply. Is there anything you would want to be cautious about when moving to more delegated sub-accounts?

[mzimmerman]

We are mostly using sub-accounts for analytics and more granular control, rather than delegated administration, but I'd say that if you are setting up college-level admins, look carefully at the admin role permissions, and consider setting up custom admin roles to grant only the specific permissions that you want those folks to have.

The other thing is, if you are using SIS integration to create your courses, consider how you will update those SIS feeds to include the necessary sub-account setting for the course.  That is the primary reason for us having an additional level of sub-accounts for each subject, so to that we can just include a subject code based on the course ID, and the course will automatically fall under the correct college sub-account....

[melodyc_lam · Accepted solution]

@Chris_Beks Welcome! This is a really good question.

Some context: I'm the Canvas Admin for a very large K-12 district with around 160K users and (currently) 186 schools. What I will say here may or may not work for your institution and your needs. 

In our district, we have subaccounts for each of our 186 schools. These schools are under a parent account representing their grade band (roughly Elementary, Middle, High, Specialty). We also have subaccounts for central office departments and also for 'staging' purposes (blueprinting, archival, etc)

Some reasons why you may want a "deeper" subaccount structure:

• Applying particular settings such as Canvas for Elementary to a subaccount
• LTI installation by subaccount (especially if only one school needs the LTI)
• Analytics is 'easier' (there are limitations still with Admin Analytics because we are so large, though)
• We can assign specialists that support particular grade bands to their assigned grade band to the parent subaccount which then lets them have access to all the child subaccounts.
• Assign subaccount admins for support.
• It's much easier to search for courses and users, and filter by terms since you can search within a subaccount (this is really huge for a district our size).
• Global Announcements can be sent to subaccounts specifically so that only a particular school or group of schools gets an announcement.
• Subaccount theming -- we don't do this but it is possible to theme each subaccount with a particular college's logo or requirements
• Archival of previous year's courses -- you can move courses into a "archive" subaccount to ensure that subaccount admins only see current term year courses.

Some things to think about as you're working through how you want this to work:

• You can only readjust the structure of your subaccounts using a SIS import file (even if you're not using a SIS).
  • If these subaccounts have courses in them and you're doing a huge re-alignment, this import may take a while.
  • Only one SIS import can run at a time and other SIS imports will be queued up, so if you are readjusting subaccounts, either do it a few at a time or stage the change during a lower period of activity in your instance.
• If you have a SIS and you have courses mapping to subaccounts, be aware that your SIS may undo some of your changes.
  • Make sure you use the "Process as UI Changes" checkbox so that this doesn't happen.
• Subaccount admins that are added within the UI can't be managed using a SIS import file.
  
  • Think about how you want to manage subaccount admins as an institution.
  • An option: you can have your subaccount admins manage the list themselves for their school.
• Think about your settings and feature options as they stand right now, and whether or not you want subaccount admins to be able to change these settings.
  • You may have to go back and lock settings do that they can't be changed by subaccount admins.
• Some permissions will only be available at the root level -- for example, subaccount admins can't act as another user unless you set up the permissions at the root level.

Let me know if you have any questions! Hope this helps 🙂

[Chris_Beks]

Thanks for your detailed reply, @melodyc_lam! I appreciate it, and a lot of it makes sense to me. We're currently a little hesitant to create additional sub accounts because reversing the structure seems to be a difficult and time-consuming process. Thanks for your response!

[melodyc_lam]

You're welcome, @Chris_Beks!

This might alleviate that concern with 'reversing the structure' - you may want to run a report on your courses as they stand before the change. That way, when you need to "undo" the change you can prepare the "undo file" from the backup file. 

[paul_fynn]

Potentially a very naive question on my part @melodyc_lam ;

Are Canvas subaccounts real or virtual ?

What I am asking by that is how much of the sub-account processing impacts how and where courses are stored, and to what extent is the sub-account structure merely an alternative virtual 'view' for users that also reflects access and permissions ?

The reason for asking this is the observation that none of the addresses or API calls that I have seen actually reference sub-accounts, any more than they reference, for example, Term dates. Hence my suspicion is that the sub-account structure isn't much more than a layer over the data structure ?

[melodyc_lam]

@paul_fynn That's probably a question that a Instructure engineer could answer fully, but I think the way it's setup, subaccounts have to keep track of who their parent is and who their children are for permissions purposes -- and that data probably sits in a table in their database.

[Chris_Hofer · Accepted solution]

Hi there, @Chris_Beks ...

I can give you a couple examples from experiences I've had with sub-accounts.

My first example was when I worked at a Technical College in Wisconsin.  I'm not sure if this sub-account structure still exists the same way (it's been a couple years) as when I left, but this is what I recall:

• Sub-account 1 (Dean access)
  • Sub-sub-account A (Associate Dean access)
  • Sub-sub-account B (Associate Dean access)
  • Sub-sub-account C (Associate Dean access)
• Sub-account 2 (Dean access)
  • Sub-sub-account D (Associate Dean access)
  • Sub-sub-account E (Associate Dean access)
  • Sub-sub-account F (Associate Dean access)
• Sub-account 3 (Dean access)
  • Sub-sub-account G (Associate Dean access)
  • Sub-sub-account H (Associate Dean access)

As you can see from this configuration, we had three main sub-account, and then sub-sub-accounts under them.  Associate Deans could only see their own sub-sub-accounts (for example, an Associate Dean in B could not see the courses in C).  However, the Dean for a main sub-account had access to all courses in the sub-sub-accounts.  For example, the Dean for sub-account 1 could see the courses in A, B, and C ... but not for D, E, F, G, or H.  This helped for our ReadyGO (Cidi Labs) LTI integration so that Deans and Associate Deans could get reports for their own programs.

At my current job (an art college in Detroit), we have approximately 45-50 sub-accounts...none of which are nested within each other.  Each of these sub-accounts is their own separate program.  For example: LIBERAL ARTS, FOUNDATIONS, ILLUSTRATION, etc.  Our Chairs and Program Managers have access only to the sub-accounts they oversee (similar to my first example).  At some point, we may consider pairing down the number of sub-accounts we have to try and combine things a bit more, but that is a conversation we'll have to have with a number of different folks at my college.  We've been using DesignPLUS (also from Cidi Labs) to design course templates, and one goal we have is to provide customized template pages at the sub-account level for anyone in a specific program to import/add into their own course pages.  We also use Cidiscape (yet another Cidi Labs product), and although we haven't set up this part yet, we can set Cidiscape up for our Chairs and Program Managers to get important information about courses in the program areas.  We're also looking at possibly purchasing ReadyGO so that our Chairs and Program Managers can get a better idea on if our courses are ready for the start of a given semester.  And, we can ensure that they only have access to their own courses...all because of sub-accounts.

I hope my examples and use cases help in some way.  Looks like you've gotten some great feedback so far, and I look forward to seeing more people post their setups!

[Chris_Beks]

Thanks @Chris_Hofer ! I appreciate your response and insights into how we could structure ours and some tools to make that process easier.

[paul_fynn]

We were 'given' a faculty structure (4) when we rolled out Canvas and have been severely constrained by not being able to get our five faculty schools and their three disciplines coded as separate sub accounts.

Deeper sub accounts given the choice !!

[NoahBoswell · Accepted solution]

Hi @Chris_Beks ,

I know I'm a little late to the discussion but I wanted to tell you how our school district has things set up (we are k12). Under our root account, we have a sub-account for each school. Each of our elementary schools have their own, the middle school has their own, and the high school has their own. Then, we have another sub-account underneath the root-account that houses things such as student and faculty professional development courses. Then, we have another sub-account for the canvas courses associated with any school clubs, as each club has their own canvas course, and then we have another one for sandbox courses that admins, teachers and TAs have.

I hope this helps too!
Noah