Hi, Dave:
Here at UC Santa Cruz we implemented sub-accounts for a few reasons:
1) We have our Student Information System (Peoplesoft) create a course shell for each course in each term. We created a hierarchy of a top folder for the SIS system / Division / Department for the course shells. The hierarchy under this matches what is in our Peoplesoft system. This will allow us in the future to grant access at the division and department level to admins in those divisions / departments, so they can access reporting at their appropriate sub-account level. We can also facilitate blueprint courses, rubrics, and LTIs specific to a department or division (paid for by them, and not available to other departments / divisions) by having these sub-accounts.
2) We also have some sub-accounts outside the SIS-managed sub-accounts for things like:
- a place where we give our student workers admin-level access so that they can experiment and learn without having access to live courses and grades
- a place where we can do testing in Production without being in the same sub-accounts as live courses
- Manually Created Courses are outside of the area where live courses are being created and managed
- We will have some non-academic sites (they were called project sites in Sakai), and they are going into a sub-account where we can give different permissions than we want to have available in the live course area managed by our SIS system.
The primary drivers were: reporting at the sub-account level, varying permissions at the sub-account level, third-party apps access managed at the sub-account level.
Hope this helps.
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.