Domains for Community Engagement
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. Domains do not restrict access to data through integration frameworks including Building Blocks and REST APIs.
Domains are available only if your school has access to community engagement features.
Domains offer a customizable, flexible, and secure system administration model. Domains gather courses, organizations, users, tabs, and modules into defined sets called collections. Each domain can have one or many collections. Once established, administration of a domain is controlled by assigning system roles to users that only apply to that domain. For example, administration of all users in the Law School can be assigned to Law School staff and administration of all the users in the Business School can be assigned to Business School staff.
The above example is a simple one. Because privileges, at the feature and function level, can be used to define unlimited system roles, there is a limitless variety to how system roles are applied to domains. The flexibility of domains means that planning the administration model is a critical step. Please contact your account manager for information about engaging Blackboard Global Services with assistance in planning and implementing an administration model.
What Domains can do
The following lists some of the goals that can be accomplished with domains:
- Organize users, courses, organizations, tabs, and modules into groupings.
- Delegate administration of users, courses, organizations, tabs, and modules.
- Assign different administrative responsibilities to different staff members within a domain.
- Control domain administrators' access to specific features within a domain by defining privileges.
What Domains are not designed to do
The following lists some of the restrictions on domains:
- Domains are available only if your school licenses community engagement.
- Domains are designed to be flexible and do not adhere to any hierarchy within the system. Domains can be defined to overlap or even nest, but that structure is applied. The domains do not have a relationship within the system.
- New items, such as courses and users, that meet the constraints of a domain are included in the domain when created. Domain administrators may not control the default attributes of items at creation. For example, a domain administrator cannot require that all new courses created in the domain adhere to specific default values.
- Domains are designed to manage collections of courses, organizations, users, modules, and tabs. Domains can include one collection or many. For example, a domain may only include courses or a domain may include courses, tabs, and users. Domains are not used to manage other items in the system such as tools and Building Blocks.
- Domains do not restrict access to data through integration frameworks including Building Blocks and REST APIs.
Terminology
The following is a list of terms and definitions required to understand domains:
Domain: A grouping of data defined for the purpose of delegating administrative responsibilities to other staff members.
Collection: A set of data, defined by variables or selected individually, that appears in a domain.
System Role: A role that grants administrative privileges. When applied in a domain, the privileges are only valid when working with data in the domain. System administrators can define an unlimited number of system roles and assign privileges to hundreds of administrative functions through each system role. Each user may have multiple system roles assigned.
Category: A variable that defines and groups courses. Courses may be assigned multiple categories. Categories are a logical means of assigning courses to a collection.
Institution Role: A variable that defines and groups users. Users may be assigned multiple institution roles. Institution roles are a logical means of assigning users to a collection. Institution roles control what content is presented to users.
Availability: Determines access. Courses that are unavailable are only accessible by certain users. Likewise, a user that is unavailable may not access the system.
Enabled: A flag set by Snapshot. Data is often disabled to mark it for archive or deletion.
Datasource Key: A variable assigned to data added to the system through Snapshot. When Snapshot is used to integrate with other information systems, Datasource keys can be used to define collections based on the source of the record.
Default domain
Every system has at least one domain. This domain includes all the courses, organizations, users, tabs, and modules on the system and is referred to as the default domain. Users with a system role of System Administrator have full privileges over the default domain (the entire system).
This concept is important when assigning system roles. System roles can be applied within a domain to grant privileges restricted to the items that exist in that domain. Or, system roles can be applied directly to a user, granting privileges in the default domain (the entire system).
Domain administration
Administration of domains is assigned by combining a user record with system roles within the domain. Each domain administrator can be assigned any number of system roles. The privileges included in these roles are additive, so they can be combined to create several different models of domain administrators. The same user can be an administrator in multiple domains.
