The next natural implementation phase following template design is to understand how you will go about administering Concourse as a whole. 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-level. At the top are system administrators will have access to all the “inner workings” of Concourse. Just below them fall domain administrators. These are folks who are largely responsible for a particular function (e.g. auditing) within a specified area (e.g. department of biology).
Once you’ve completed the three exercises described in this article (examples and exercise templates attached at the end of this article), you should have a comprehensive understanding of how you will go about administering Concourse. This will also lead you to the final step of the implementation: Integration.
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.
Below is an exhaustive list of all the functions administered at the system-level. We encourage you to fill out the related table (available as an attachment at the end of this article) with either the name(s) of the specific individual(s) or titles that should be granted this type of access at your institution:
- Administer System: Allows a user to handle system-wide functions, including:
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
Create Courses: Allows a user to manually create new or cloned courses.
When you are ready these three system permissions can be assigned to users individually through the Admin > Users area.
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.
One concept that is central to domain administration is scope, that is 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:
Again, what is key is how you plan on distributing the responsibilities of Concourse management.
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, 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, department triplet of Template-Template>Template. In fact you can further breakdown template management with Template-School>Department domains for more complex/distributed template administration.
For all the gory details on how to work with domains, see this article.
Once you have the structure down you can begin determining what domain permission should be assigned to which individuals.
There are three domain-level permissions, highlighted below.
Administer: Can edit syllabus content, change settings, and manage registrations within a course. Typically a handful of individuals would have this permission, such as those supporting end-users or managing templates.
Audit: Can view all content and set course audit status to Reviewed. May also get audit update emails. Note that someone with audit permission alone cannot syllabus content. Typically, Deans and Chairs would have audit permission for courses in their respective school(s) and department(s).
Report: Can view all syllabus content, effectively allowing for comprehensive report generation. Those in the assessment or institutional effectiveness office may be interested in this.
These domain permissions can be described pictorially. Note that the Report (i.e View) permission is a superset of both administer and audit meaning it does not need to be explicitly set for individuals with either of the other two domain permissions.
What may be a more important decision surrounding domain permission is just how distributed you expect said permissions to be. In smaller implementations it’s likely that there will be a core few people that will administer and audit all courses. In fact they will likely be system-level administrators as well.
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.
Now let’s combine the knowledge of domains into a chart that together showcases how one might administer Concourse with the following requirements:
Academic Affairs: To maintain template content and settings; occasionally audit courses and generate reports
Deans: Audit all template syllabi, Report on instructional syllabi within 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
At the end of this article you can download a spreadsheet to assist you in developing your own domain structure listing as well as a blank version of this matrix. You will also see how our four sample schools went about completing this exercise.
Then you can go here to learn about assigning domain-level permissions.
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.