Blackboard recommends using Institutional Hierarchy features in place of Domains in most cases. Institutional Hierarchy enables fuller utilization of other Learn functions and doesn’t require logic based on custom rules.

The most important part of using domains is developing an administration model that matches the organizational needs of the Institution. This topic walks through the process of thinking about the administrative needs of the Institution. Included are questions to ask at each stage and a small example.

Remember that this is a tool to help you start thinking about your administration model. The flexibility of domains and unlimited system roles create the opportunity for unique solutions to match each Institution.

What are the groupings on campus that require domain management?

The first step in setting up a delegated administration model is to define the groups at the Institution that can be supported by delegated administrators with privileges limited to that domain. Because domains can include any combination of users, courses, organizations, tabs, and modules the structure of the different domains is limitless. Some Institutions may choose to use domains to separate management of users between students, faculty, alumni, and staff. The same Institutions can use domains to separate management of courses between academic departments. The same Institutions can even apply both models, and allow the academic department domain administrators control over users in their respective departments. Further, each department could be divided into separate domains. One domain could be used to manage the tab and module content while another domain managed courses and still another domain handled users.

The flexibility of domains demands clear goals and organization before creating the domains and assigning administrative privileges. Otherwise, it is likely that domains will be created as needed and result in a system that is difficult to define and oversee. Consider the following questions when defining the groups on campus that require domains:

  • How is the Institution organized and managed? Does it make sense to create domains for each functional group? Consider this question beyond just academic departments and think about the groups on campus that support the learning mission.
  • How are institution roles used to define users within Blackboard Learn? For example, are users organized by major, location, year of study, or other variables?
  • How are individuals at the Institution managed? Are the different sets of users managed by different functional groups? For example, is there an alumni office that handles alumni relations? Is the admissions department responsible for prospective students?
  • Who is responsible for the content that appears in tabs and modules? What institution roles are used to define who can view content?
  • Are there different information systems responsible for shared data with Blackboard Learn?

It is very likely that the groupings on campus will have subgroupings that also require delegated administration. Subgroupings cannot be nested as domains within a domain, but this is not a barrier to creating a hierarchical structure of domains. Because domains are made up of collections, and a unit, such as a course or user, can appear in multiple collections, it is easy to define domains that consist of a subgroup of another domain. To maintain the proper organization, develop a naming convention for domains that incorporates the larger domains. For example, the School of Liberal Arts will likely have several subdomains for academic departments.

The domains could follow this naming convention:

SLA - School of Liberal Arts

SLA_HISTORY - History department, School of Liberal Arts

SLA_ANTHRO - Anthropology department, School of Liberal Arts

SLA_LANGUAGES - Languages department, School of Liberal Arts

SLA_LANGUAGES_FRENCH - French courses, Language department, School of Liberal Arts

How is each domain defined?

Each domain is defined by assigning criteria to create sets of users, courses, organizations, tabs, and modules. Each set is called a collection. A domain can include one or many collections. Once the domain structure is defined, items, such as users and courses, are grouped into collections within the domain. Adding the collections is a process of defining the collection in such a way to encompass every item that should be included. When new items, such as a user or a course, are added to the system, they automatically become a part of any domain for which they meet the collection criteria. For this reason, it is important when defining a collection to use the criteria and the rules to determine the items that fall into the collection to ensure that new items are added to the collection when created. There is an option to add items individually. The ability to add items individually is useful for defining domains that are limited and static, ensuring that no other items become a part of the domain.

It is much easier to define domains after first setting up a model for institution roles and a model for course and organization categories. These variables are completely customizable and serve as the most flexible and accurate way of defining collections within a domain. Institutions that are using Snapshot to populate the Blackboard database with data from other systems can also use data source keys to define collections.

Finally, there is no relationship between the users in a domain and the courses and organizations. That is, users enrolled in a course are not automatically included in the domain. Within a domain, enrollments are controlled by courses. Thus, a domain administrator with privileges to edit users may not change users' enrollments in a course. However, a domain administrator with privileges to edit course enrollments may include or exclude users from a course.

When defining collections, consider the following:

Courses and organizations

  • What categories can be used to define the courses and organizations in this domain?
  • Alternatively or in addition to categories, what data source keys can be used to define the courses and organizations in this domain?
  • Should the domain include unavailable courses and organizations? Should the domain include disabled courses and organizations? This is an important consideration as unavailable and disabled status is often used to mark courses and organizations that are complete and scheduled for archive.
  • Should the courses and organizations in the domain be limited by enrollment options, for example, courses in which students can enroll themselves?
  • Course and organization categories must be added individually, even if the category is nested in a category that is already included in the domain.

Users

  • Which institution roles can be used to define the users in this domain?
  • Alternatively or in addition to institution roles, what data source keys can be used to define the users in this domain?
  • Users may also be defined by system role. However, customized system roles are more likely to be based on privileges and thus are not usually a good model for defining the users in a domain. System role is most useful as an attribute when using the guest or observer role.
  • Should the domain include unavailable users? Should the domain include disabled Users? This is an important consideration as unavailable and disabled status is often used to mark user records for archive or removal.
  • Should the users in the domain be limited by privacy options? Users that opt out of the User Directory can be excluded from a domain.

Tabs and modules

  • Should the domain include unavailable tabs and modules? This is a way to allow users to create tabs and modules but not edit them once they are published. Alternatively, a domain can include only available materials. In this case, the unavailable materials that are in production cannot be edited by the domain administrators.
  • Tabs and modules can be individually selected for inclusion in a domain.

For example, consider populating the SLA_LANGUAGES domain with a collection of courses and users that includes all the courses offered in the department and all the users that work in the department or list Languages as their major of study. In this case, the courses collection may be defined as:

Categories: LANG, LANG_FR, LANG_DE, LANG_ES, LANG_JP, LANG_NL

Availability: Ignore

Enabled: Enabled Only

The user collection may be defined as:

Institution Roles: DEPT_LANG, MAJOR_LANG

Availability: Available Only

Enabled: Enabled Only

Which administrator tasks are required for domain administrators?

After the collections are defined it is possible to confidently assign appropriate privileges to system roles. Domain administrators are granted privileges based on a system role that is applied to that domain only. Essentially, the user and the system roles are combined to create a delegated administrator for the domain with the privileges defined by the system roles. That combination of user and system roles only applies in that domain.

System roles can be created for each domain, but it is more efficient to create system roles based on like privileges that can be applied to an administrator in each domain. Because system roles are additive in the domain, it is possible to create a system role model based entirely on tasks and then use a combination of those tasks to grant individualized privileges to specific delegated administrators.

When creating system roles, consider the following:

  • What administrative tasks will be used by domain administrators?
  • What privileges are needed to accomplish these tasks?
  • How can those privileges be grouped so that each set of privileges accomplishes a goal or goals? Are there any privileges that are not always applicable in the set?
  • How should system roles be named? The naming convention should be easily recognizable and define the set of privileges.

For example, a system role named USER_MANAGER is created with full privileges to manager user accounts. This system role can then be used in each domain to grant a domain administrator the ability to administer all user accounts in the domain. Another system role, USER_PASSWORD may be granted to a domain administrator to allow that user to change users' password, but not edit any other details about the user record.

In the SLA_LANGUAGE domain, the department head may be given the role USER_MANAGER, while an assistant is assigned the USER_PASSWORD system role in the domain to respond to requests to replace a lost password.

Remember that system roles are additive. If a user has the system role of USER_PASSWORD, and is given another system role that includes the capability to edit some aspect of user accounts, both system roles apply. That is, the user has the sum of all the privileges of all the system roles the user is assigned. Further, if the user has system roles with administrative privileges assigned on the default domain, those privileges apply in all domains and for all data in the system.

Who are the users assigned to administer the domain?

Domains are not limited to one administrator with one system role. Rather, each domain can have an unlimited number of administrators with an unlimited number of system roles. In a domain, different administrators are assigned different responsibilities and tasks.

When assigning users as domain administrators, consider the following:

  • What aspects of the domain require a domain administrator?
  • Are there specific system roles that grant privileges to accomplish these tasks without introducing additional unnecessary or potentially risky privileges? If not, consider revising the construction of system roles or creating a new system role to cover the exceptional case.
  • How do the required tasks form the responsibilities for domain administrators? Is one admin required to manage users while another is assigned courses?
  • Who should be assigned to the different domain administrator positions?

After the individuals who will serve as domain administrators and the system roles that will grant appropriate privileges are identified, the last step is to put that information together within the domain. For example:

Domain: SLA_LANGUAGE

User: Department Head

System Roles: USER_MANAGER, COURSE_MANAGER, MODULE_CREATE, MODULE_MODIFY