Administering Concourse as a whole is a huge step of any implementation process. For example, what level of access should a Dean have? Who will be able to configure integrations? Load courses in bulk?
This article describes the two highest tiers of Concourse administration, system and domain permissions. These are the highest level of permissions in Concourse and are leveraged on a user by user basis. Typically, those who have either system or domain permissions have more responsibility within the Concourse platform than the average faculty member would have access to: reports, multiple syllabi in a given set of disciplines, etc.
The highest level of Concourse administration is at the system level. Individuals here will be responsible for the setup of domains (below), integration with other systems, permanent removal of courses, and assignment of lower-level administrators, just to name a few. As you can imagine these are folks who should be the most expert and trusted regarding all the Concourse functions and be limited to a very small group of people. In most cases we find that a few individuals from IT together with Academic Affairs (and possibly eLearning if they are separate) take on these responsibilities.
The assignment of additional system administrators (i.e. the three main rights bulleted here)
The processing of feed files for bulk user, course, registration, and content creation
The setting of course and item-level permissions en masse
The permanent purging of courses and users
The organization and labeling of domains
The configuration of LTI-based integrations
Set Domain Permissions: Allows a user to set domain-level permissions for other users. (This does NOT give a user domain permissions)
Create Courses: Allows a user to manually create new or cloned courses.
Domains refer to the second tier of Concourse administration, which is typically (but not necessarily) mapped to the organizational structure of your institution, such as campuses, schools, and departments. What is important to remember about domains is that they should model how you anticipate distributing the administration of Concourse in terms of managing templates, providing auditing capabilities, granting reporting rights, and general support access.
How is your institution organized now? What administrators will need to access Concourse, and what will they need to be able to do? Do you have a process for auditing course syllabi and who’s involved? Template maintenance? These are important questions and the answers will affect your domain setup.
In addition to provisioning one of the domain roles above, one concept that is central to domain administration is establishing scope over what “range” of courses will the administrator be able to perform their duties. These are formed by mixing and matching triplets (campus + school + department) to create an appropriate set of domain permissions for an individual. Here are four examples of how access may be granted to individuals with various responsibilities in your institution:
Provost: Will be able to operate across every course (i.e. all campuses, schools, and departments).
Dean: Will be able to operate within their school regardless of campus location.
Chair: Will be able to operate within only their department.
Site Director: Will be able to operate across schools and departments at their location.
*Note: Although “Campus,” “School,” and “Department” are the default labels used in Concourse, the Syllabus Geeks can relabel these to fit your institution. Some other combinations we’ve seen include:
Campus-Division>Department
Campus-School>Program
Campus-Division>Cluster
Level-Discipline>Program
Again, what is key is how you plan on distributing the responsibilities of Concourse management.
As the complexity increases and responsibility gets more distributed, you may find that you add a few designated auditors from each school, and later each department, not to mention those administering templates. At this point, you can imagine that you are managing domain permissions for say less than 100 individuals.
For the most dispersed situations, say where there are also select faculty members who are simultaneously content experts managing a small subset of a massive template collection (i.e. >100 administrators), it is likely that domain-level permissions will need to be combined with course-level permissions to make the situation manageable. If this sounds like you, get in touch.
To help you get thinking about how you'd leverage the different domain sets and roles, here is a list of common positions/departments that one might need domain permissions with varying levels of responsibility:
Academic Affairs: To maintain template content and settings; occasionally audit courses and generate reports
Deans: Audit all template syllabi, Report on instructional syllabi within a school
Chairs: Audit all instructional syllabi
Site Directors: Report on instructional syllabi at their campus
Institutional Effectiveness: Generate outcome reports
Faculty Developers: Support instructor training and help resolve issues
As you go about determining the segmentation of responsibilities for your Concourse administrators, it is helpful to understand the two primary constraints about how you may elect to organize your domains. The first is the relationship between campuses, schools, and departments, as shown below.
Within Concourse two important relationships exist:
Campuses are related to Schools, and
Schools are comprised of Departments.
This will have a material impact on how you label and organize your domains, namely that:
every department must belong to one and only one school,
a school can be associated with multiple campuses, and
each course must relate to one and only one department, school, and campus.
The second consideration is that each domain listing must consist of a name (e.g. Accounting) and unique external ID (e.g. ACCT) pair. Being able to match the external IDs with something your student information system can easily generate is particularly important if you eventually expect to automatically create courses from feeds in the next phase of your implementation.
*Note: If your organization is small, does not have campuses, or all syllabus management will be performed centrally, you may not need to take advantage of such thinly sliced segmentation and can drastically simplify your implementation. For example, if you never expect to assign domain permissions for a campus, you might include a single Campus called “All” to represent every school, and department. You can always expand the granularity of domains at a later time as the complexity of your implementation grows.
Since a large motivation for implementing Concourse is often the ability to distribute template (both uploaded or structured) management, we dedicate a section here to how these play a role with domains.
Let’s say you have a template for Calculus 101. Should this course be placed in the Main-Science>Math domain? Not necessarily, because it’s not only for the Main campus. Or what about the institutional template which applies to every campus, school, and department?
Furthermore, what if you want to have a dedicated team of people to manage templates separate from chairs who up till now are able to edit all syllabi in their department?
For this reason, it is usually necessary to introduce a “dummy” domain to organize templates, in other words, a campus, school, and department triplet of Template-Template>Template. In fact, you can further break down template management with Template-School>Department domains for more complex/distributed template administration.
There are a few other points to keep in mind when deciding how you will administer Concourse.
Growth: First, give some consideration for growth. Given how intertwined administrative domains are with templates and integration, it behooves the implementation team to think about future adoption possibilities as the institution expands or restructures. For example, even if you are a single department piloting or using Concourse, think about what the solution might look like at full scale. Even though campus might not make sense for you right now and you may be tempted to change it to something like "program," is that in the best long-term interest of everyone later on?
Test: Try everything in the sandbox first. See how different domain structures fit your needs. Assign permissions. Create dummy accounts to experiment with interactions. Try to edit content or audit syllabi you should or shouldn’t have access to. All of this is especially important as a predecessor of template design but before you embark on integration and automation.
Simplify: Don’t attempt to cover every nuance of every situation from the get-go. Start with a simplistic administrative structure with only a few administrators assigned. Centrally manage templates (or even start without templates and allow faculty to upload existing syllabus documents). Hold off using audit until a future term. Maybe you needn’t assign reporting capabilities because your guest access doesn’t restrict any content. The key is introducing complexity over time and only when it’s needed.