In Brightspace, the organization (org) is the top tier of the organization unit type hierarchy. Within an org, there are org units, the standard building block of Brightspace. Org units are organized into an org structure and can have multiple org unit types (for example, department, semester, or course offering). Each org unit has an org unit code used to identify it between Integration Pack for Student Information Systems (IPSIS) and your Student Information System (SIS).
Org administration tasks include:
- Define an organization's structure with the Org Unit Type Editor
- Define org units within an organization with the Org Unit Editor
- Create, import, enroll, and manage users with the Users tool
- Search and navigate the org units in which learners are enrolled with the My Org Units custom widget
- Configure tool functionality with the Config Variable Browser
- Customize the login page with the Login Page Management tool
- Set a language pack with the Manage Languages tool
- Configure cultural formatting and languages with the Manage Locales tool
- Define locations in your organization with the Locations tool and assign seats to learners with the Seating Chart tool
An org structure is a software architecture construct designed by D2L to offer maximum flexibility to our clients when creating their online learning presence. It resembles a tree structure of organizational units (often referred to as org units), with each org unit typically, but not necessarily, representing a group of users or particular organization level within the client's business model. For example, the root level of the org structure could be a university, a ministry of education, or a corporate organization. Because of the tree-like structure, there is a path of descendants from a particular org unit down to a leaf node, and a path of ancestors up to the root node. The path between the organization structure root and the leaf nodes (courses) may include several layers of academic faculties, schools, academic or corporate departments, and so on.
While mostly shaped like a general tree, org structures are actually directed acyclic graph, since it is possible for certain nodes to have more than one ancestor. In order to avoid circular routes when tracing ancestor and descendant paths, D2L places a restriction that no two org units on a path can be of the same org type; however, it is still possible to have a flexible org structure with this restriction in place.
Org Units and Org Unit types
Every org unit has a specific org unit type. There are three of org unit types:
- System-defined org unit types are pre-defined by the Brightspace platform and exist when a client sets up their instance. For example, Organizations.
- Custom org unit types are created by users through the Config Variable Browser. For example, Facilities.
- Common Custom org unit types are created by users, but are not created through the Config Variable Browser. They have special properties within the Brightspace platform. For example, Departments.
While all types of org units share common properties, such as ancestors, descendants, and the ability to enroll users, org units that belong to either the System-defined org unit type or Common Custom org unit types have additional features and properties as listed in this section of this article. These features and properties are common in most organizations; however, they are not necessarily applicable in all organizations.
Note: Org units of the same type cannot be part of the same ancestor or descendant path within an org structure.
When you work with org unit types, D2L recommends that you try to keep the organizational structure as simple as possible for your implementation. Complicated organizational structures generally result in a need for extensive maintenance without the benefit of added functionality. The system enforces lineage; an org unit cannot be the descendant of another org unit of the same org unit type. For example, a department cannot be the descendant of another department.
When you rename a default org unit type the change applies to all organizations on your instance, except for department org unit type. If you rename the department org unit type the change only applies to the organization where you made the change. Department type org units are the only default org unit type that you can delete. If you delete the department org unit type, it is only deleted from the organization where you deleted it. If you create a new org unit type after deleting the department org unit type and set the type to department, the system will recreate the department org unit type.
Organization Org Unit type
The Organization Org Unit type is system-defined and is typically the root node of the org tree structure, and there is only one per organization. The Organization home page is available when a user clicks My Home. Internal email address domains are assigned at the Organization level and cannot be set at any other level.
Course Template Org Unit type
The Course Template Org Unit type is system-defined. Course Templates store files and data that is common to many descendant course offerings. Course Templates can be direct descendants of Organizations or Departments. The difference between a Course Template and a Course Offering is in the frequency of the offering. Across many semesters, learners take different course offerings from the same course template. For example, CS 488 itself is a Course Template whereas CS 488 in a fall term and CS 488 in the winter term are both Course Offering. Typically, a Course Template is not attached to a Semester; whereas, the descendant Course Offering is. As result, different Course Offerings attached to the same Course Template can belong to different semesters.
Course Offering Org Unit type
The Course Offering Org Unit type is system-defined. Course Offerings are instances of a course, and are typically direct descendants of Course Templates and Semesters. To reach a Course Offering's home page, click Course Home in the Course Offering. Content, quizzes, grades, and discussions are all typically associated with Course Offerings.
Semester Org Unit type
The Semester Org Unit type can be system defined or common custom. Semesters are usually direct descendants of the Organization and organize Course Offerings into time categories. You aren’t required to have an org unit type set as a semester. For example, if your organization uses open-ended course offerings that continue for years with new users enrolling whenever they like, then you might not use a Semester org unit type. However, if you choose to not use a Semester org unit type, be aware of the following considerations:
- If you’re using SIS Integration, the mapping process assumes that course offerings are associated with semesters. If your SIS has structure corresponding to semesters, you will probably need to have this type in your D2L system as well.
- When an org unit type is set as semester, org units of that type are listed in the Semester field when creating new course offerings or editing existing ones. This field is controlled by the form element in the CreateCourse and CourseOfferingInfo forms. The name of the field is updated to match the name of the org unit type set as the semester standard type.
- If your My Courses widget groups course offerings by semester, the system uses the org units of the corresponding standard semester type to group course offerings. If no org unit type is set to semester, course offerings are not grouped.
Group Org Unit type
The Group Org Unit type is system-defined. Groups are typically direct descendants of Course Offerings. Groups separate learners into working groups for projects and assignments, or create special work areas for users with different learning needs. Each Group org unit has a group type associated with it, and multiple group types can exist in a Course Offering. For example, if there are three projects with different groups in a course, each project has a separate group type. Groups are not managed independently from an instructor or administrator's point of view; if they can see and manage one Group, they can see and manage them all.
Users can belong to any number of groups in the same course and each group can have its own discussion forums and assignment submission folders to work in.
Next Steps: You can create categories to set up, organize, and manage related groups. You must create these categories and groups before adding learners to groups. For more information, refer to Create categories and groups.
Section Org Unit type
The Section Org Unit type is system-defined. Sections are a special type of manageable Group in which instructors and administrators can see and manage only the sections in which they are enrolled. This permits multiple instructors and teaching assistants to be enrolled in the same Course Offering, but only be able to see and manage learners in their specific sections. For example, a large university Course Offering may have 2000 learners and 10 instructors. Sections enable each instructor to teach and assess the same curriculum to the same 200 learners in their respective section.
Department Org Unit type
The Department Org Unit type is common custom. Departments are typically direct descendants of Organizations. If an Organization creates a Department org unit type, users creating Course Templates through the Manage Courses interface have the option of associating the new Course Template with a Department. Departments organize Course Offerings into subject categories. Users creating new Course Offerings can observe the departments under which their new Course Offering appears.
if you choose to not use a Department Org Unit type, be aware of the following considerations:
- If you’re using SIS Integration, the mapping process assumes that course templates are associated with departments. If your SIS has structure corresponding to departments, you will probably need to have this type in your D2L system as well.
- When an org unit type is set as department, org units of that type are listed in the Department field when creating or editing a course template, and when editing a course offering. This field is controlled by the form element in the CreateCourse and CourseOfferingInfo forms. The name of the field is updated to match the name of the org unit type set as the department standard type.
- If your My Courses widget groups course offerings by department, the system uses the org units of the corresponding standard department type to group course offerings. If no org unit type is set to department, course offerings are not grouped.
Using roles, permissions, and user enrollments
The org structure architecture is even more powerful and effective when used in conjunction with roles, permissions, and user enrollments. To access a particular org unit in the org structure, a user must be enrolled in the org unit, and you must also specify the user's role. You cannot enroll a user in an org unit without a role. The role, along with the org unit type, determines the user's permissions within the org unit.
Permissions
You can manage permissions using the Roles and Permissions option of your Admin Tools to set hundreds of privileges throughout your org units. New permissions are created as part of Brightspace releases; users cannot create new permissions. Permissions are granted to roles at the org unit type level. For example, this means that if the role Teaching Assistant (TA) is given the permissions Grade Assignments in all course offerings, any user enrolled in a course offering as a TA can grade assignments.
Roles
Users can increase the flexibility of the system of permissions by adding custom roles to the default roles (Learner, Instructor, and Administrator) provided by D2L. This means that, for example, in one course offering you did not want TAs to grade assignments, system administrators could create a new role called Teaching Assistant 2 (TA2) which had all the same permissions as the original TA role except the permission to grade assignments. Then instead of enrolling users as TAs in the one course offering that was different, they could enroll as TA2.
Roles and Enrollments
The org structure does not restrict users to the same role across the entire organization. It is possible for a user to be an instructor in one Course Offering and a learner in another without the possibility of the using their instructor permissions to modify grades in the course where they are a learner. Complex interactions between users, roles, and security is possible using the org structure. For example, a user may be an administrator in every org unit in the platform except a single course where the user is a learner. This scenario is unlikely, as Administrator is a cascading role, but it is possible.
Org Structure Access
The Org Structure itself is not governed by explicit role permissions as are other domains in Brightspace. All users enrolled at the organization level have implicit access to some details about the Org Structure, regardless of their designated role. A user can access the Org Structure details only after the user has authenticated and logged into the organization. Aspects of the Org Structure that are visible to all users enrolled at the organization are as follows:
- Individual Org Unit Properties, such as Org Unit Name; Code; Org Unit Id; Start Date and End Date; whether the Org Unit is Active or Inactive; Org Unit Description; Org Unit image.
- Some route endpoints into other domains that the user may be able to access depending on permissions in other domains.
- The Org Unit’s ancestors' details if the user is entitled to see them (such as Individual Org Unit Properties above). This can be used to traverse or model the Org Structure as a whole.
Users do not have to be enrolled in an org unit to see details of that org unit. Any enrollment in the organization is sufficient to grant access to any of its descendants' details.
Implicit access to the Org Structure is read-only. Users are not implicitly given access to modify the Org Structure, or any details of any of the org units within it.
Although the user has implicit read-only access to the Org Structure in this way, the Brightspace user experience, including API endpoints, may still restrict this access further, for example by hiding org unit details where the user has no enrollments.
Permissions granted in a different organization within the same instance are not considered. That is, a user logged into organization A will not necessarily be granted access to the Org Structure of organization B on the same instance.
Unauthorized Access
If a user tries to access an org unit in which they are not enrolled, they will receive a Not Authorized error message. Similarly, if a user tries to access an org unit in a role which does not grant them access permissions to the page, they will also receive a Not Authorized error message.
For additional information, refer to About Org Unit Editor and About Org Unit Type Editor.